GMP 6.3.0: Failure building on MinGW (defaulting to ABI=64)

Simon Sobisch simonsobisch at
Mon Dec 11 09:35:41 CET 2023

Am 10.12.2023 um 22:51 schrieb Marc Glisse:
> On Sun, 10 Dec 2023, Simon Sobisch wrote:
>> $ ./config.guess && gcc --version && as --version
> gcc -v file.c
> gives more information about the assembler that is really used.

Thank you for the note, I'll use this next time.
On this specific machine there is only the old GNU assembler available, 
so it is quite sure that this was used.

>> gcc.exe ( GCC Build-2) 9.2.0
> gcc-9 is old.

Yes. I also run some GCC 4 on an old Linux kernel (also 32 bit) from 
time to time (but haven't checked GMP 6.3 there).

I did not found a note about the minimal GCC version to build GMP - is 
there a documentation about that? (I see no reason why GCC 9 should not 

> Isn't abandoned? I thought everyone had moved to

"partial"; is down so the downloading does not work any more so 
you can only install from a mirror or a backup, but of course existing 
installations still work.

I _guess_ binaries from will need a "relative recent" 
version of the Windows operating system; "good old MinGW" still works 
fine with Windows XP (last time I've checked also with older versions); 
therefore using it to keep "legacy" environments up-to-date is still 
... and most other mingw binaries I've seen are much bigger than the 
ones originally distributed by

>> using ABI="64"
>>      CC="gcc"
>>      CFLAGS="-Wno-attribute"
> Specifying CFLAGS yourself is not a great idea, it prevents GMP from 
> adding nice optimization flags. If you really want to pass 
> -Wno-attribute, either put it in CPPFLAGS, or run configure once without 
> CFLAGS to see what GMP wants to use, and add -Wno-attribute to that.

Good point. I've moved it to CPFFLAGS:

   configure ABI=64 CPPFLAGS="-Wno-attributes -Wno-ignored-attributes"

The question is still why the ABI 64 is chosen on this system. Any idea?

>> This error seems to be related to changing the ABI after the initial 
>> configure. Using "make distclean" fixes this.
>> I therefore think that something like `AC_ARG_VAR([ABI], [Application 
>> Binary Interface to use])` (maybe also reference 
>> in its description) should be 
>> added to to make that error on an ABI change and also 
>> adding this missing piece to configure's help output.
> You mean this?
> I think it has been there for a while.

Yes, exactly this. And executing
    ../configure --help | grep ABI
I also see the help output.

But somehow the documented result [1] of being precious

 > The value of variable when configure was launched is saved in the
 > cache, including if it was not specified on the command line but via
 > the environment.
 > variable is checked for consistency between two configure runs

did not trigger: first not specifying [and leading to ABI=64], then 
specifying as ABI=32, did neither resulting in a configure error nor did 
it reused the old value.



More information about the gmp-bugs mailing list