gmp required ABI=32

Ken Moffat zarniwhoop at ntlworld.com
Wed Nov 12 03:25:08 PST 2008


On Wed, Nov 12, 2008 at 09:32:16PM +1100, Greg Schafer wrote:
> Ken Moffat wrote:
> 
> >  My box built gmp and the first part of chapter 6 during the night
> > without any apparent problem.  The host system was LFS-6.3 with a
> > current kernel.
> 
> I just looked into this. It appears the bug only tickles when CFLAGS are
> set. ie: if CFLAGS are set in the environment, it guesses the wrong ABI
> when building 32-bit x86 on 64-bit AMD hardware (not sure about Intel).
> You can easily reproduce this by setting CFLAGS then running ./configure.
> Issue is exacerbated due to GMP's "tricked up" config.guess ie:
> 
> $ ./config.guess
> athlon64-pc-linux-gnu
> $ /usr/share/libtool/config/config.guess
> i686-pc-linux-gnu
> $ /usr/share/automake-1.10/config.guess
> i686-pc-linux-gnu
> 
> The CFLAGS aspect at least explains why everyone is not seeing this.
> 
> >  This implies Tobias has both a compiler and libc in chroot that are
> > able to handle -m64.
> 
> No. See above.
> 
> Regards
> Greg
 Agreed.  Thanks for the analysis.  With CFLAGS=-O2 it now shows

checking ABI=64
checking compiler gcc -O2 ... yes
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
...
using ABI="64"
      CC="gcc"
      CFLAGS="-O2"
      CPPFLAGS=""
      MPN_PATH=" x86_64 generic"

and continues until

checking size of mp_limb_t... 4
configure: error: Oops, mp_limb_t is 32 bits, but the assembler code
in this configuration expects 64 bits.
You appear to have set $CFLAGS, perhaps you also need to tell GMP
the
intended ABI, see "ABI and ISA" in the manual.

 So, I suppose we ought to warn people, and tell them to add ABI=32
if they are using their own CFLAGS on an AMD_x86_64 ?

 Anyone got a 64-bit-capable intel to confirm if those are also
affected ?

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce



More information about the lfs-dev mailing list