Bug in configure script for PPC64 machines
myriachan at cox.net
Tue Feb 20 01:15:15 CET 2007
The bug in configure is that it is mismatching the assembly code with the C
code. The configure script detects that GCC with no options is 32-bit, and
sets up the C settings correctly, such as by selecting 32 bits as the limb
size. However, when it selects the assembly code, it selects the 64-bit
version even though the rest of GMP was compiled for 32-bit.
After ./configure with no options, the symbolic links for the assembly code
can be seen pointing to the ppc64 directory instead of the ppc directory.
"make check" is failing because the shift assembly code is using a different
limb size than the C portions of GMP. gmp.h is generated with 32 bits at
the limb size with the broken compile.
The bug appears to be in how configure interprets the machine type string.
config.guess shows powerpc64-unknown-linux-gnu; programs like "uname" on
these machines identify as powerpc64 as well. The code in configure that
selects the assembly code for a given machine type doesn't take into account
the possibility that the compiler on a "powerpc64" machine might generate
32-bit code by default.
I don't have this machine available at the moment; however I'm guessing that
an explicit "ABI=32" will not fix it because the "powerpc64" will remain.
I'm guessing that ABI=64 *would* work.
This is a small bug in configure's assembly code selector and nothing else.
----- Original Message -----
From: "Torbjorn Granlund"
<tg-this-will-bounce-but-I-am-subscribed-to-the-list-honest at swox.com>
To: "Myria" <myriachan at cox.net>
Cc: <gmp-bugs at swox.com>
Sent: Monday, February 19, 2007 14:20
Subject: Re: Bug in configure script for PPC64 machines
"Myria" <myriachan at cox.net> writes:
The bug is in GMP's configure: it's trying to use 64-bit PowerPC assembly
code even though it detects GCC as outputting 32-bit code.
If that is a bug, then hell, GMP's configure is shock full of bugs.
But then again, since it works as documented in the Installing GMP
manual chapter, it might not be.
It should be
using 32-bit assembly code, which is why --host=powerpc-unknown-linux-gnu
works around the problem.
That's not the reason --host=powerpc-unknown-linux-gnu doesn't trigger
the kernel bug. (I realize it sounds to serious to be true that the
kernel Linux trashes user registers at random, although only in
certain circumstances. But that's the sad truth.)
Outputting 32-bit code by default is correct on
these systems, as all the other binaries are 32-bit.
You have a somewhat narrow view of correctness.
On a system that had this problem, I was able to build both in 32-bit mode
and 64-bit mod by supplying configure with the appropriate command-line
You hack around something that has a clean, documented solution.
You might want to take a good read of the section "ABI and ISA" in the
More information about the gmp-bugs