GMP, MPFR and VS version compatibility

Michael Abshoff Michael.Abshoff at
Fri Jul 13 10:51:18 CEST 2007

brg at wrote:

Hello folks,

> Hi Jim,
> Please don't worry on my behalf since I am used to people here 'dissing'
> pretty well anything to do with Microsoft irrespective of whether the
> criticism is deserved.  In this case I don't believe it is.
> Michael's problem is not one of having to re-tool as a result of MSVS
> changes since MS has always provided good mechanisms for moving projects
> from older to newer VC++ versions.  In consequence anyone who builds GMP
> with an MSVC tool chain is very unlikely to have any maintenance problems
> (I have never had any such problems in 10+ years).

That is true, but downgrading your project from one version to a previous
one is a feature that is needed. I suspect that omitting that feature
"motivates" upgrades, just like changes in the format Word uses
"motivates" people/companies to upgrade.

> The problem in Michael's case is that he wants to move _backwards_ from a
> later to an earlier version. And it's no more an MSVC issue than it is a
> GNU/GCC/UNIX/LINUX one that moving in this direction is likely to be
> problematic.

No, I disagree on that one. With Linux/Unix and gcc/make it doesn't make a
difference (within reason, my might have problems on that 10 year old
installation). but if you feel to compile GMP with gcc 2.95 it will work
(for 32 bit at least).

> In my view the major maintenance issues in providing GMP in both
> environments are those of coping with the changes needed to exploit new
> processors and new processor features. The specific GCC/MSVC maintenance
> issues are the different x64 ABI, the different assembler code tool chains
> (M4/GAS vs YASM) and the different assembler syntax (although both gas and
> YASM are now bilingual).

And as a host to a mirror for Brian's binary gmp builds I can tell you
that there is demand: There are literally hundreds of downloads from my
mirror each month.

Brian, do you have figures on how many lines of code you change and how
many file you add that are not part of the build system? That way one
could estimate if a autotools+MinGW using cl.exe+yasm port would be
worthwhile/possible. I just remembered that ATLAS used to do the same
thing (with the 3.6 release, the 3.7 has a new build system and will have
support for that compiler again in the future).

Currently the GMP port to MSVC is entirely dependent on you, so having an
alternative in case you no longer are interested in doing the work (and I
am not implying that you will stop, this is just kind of a worst case
scenario, i.e. you get hit by a comet) is a good thing.

>  best regards to all,
>     Brian Gladman



More information about the gmp-discuss mailing list