[Clfs-support] [CLFS-DEV] Embedded GMP builds 64-bit binaries when asked for a 32-bit build

Andrew Bradford andrew at bradfordembedded.com
Wed Jul 3 07:39:54 PDT 2013


Kirk,

Can we consider this fixed if we pass the --build=${CLFS_HOST} to GMP's
configure?  I believe that's what you're saying in
http://lists.cross-lfs.org/pipermail/clfs-dev-cross-lfs.org/2013-July/001484.html

Thanks,
Andrew

On Tue, Jul 2, 2013, at 09:13 AM, Kirk Terrell wrote:
> On 07/01/2013 06:14 AM, Andrew Bradford wrote:
> > On Mon, Jul 1, 2013, at 09:07 AM, Kirk Terrell wrote:
> >> On 07/01/2013 04:32 AM, Andrew Bradford wrote:
> >>> On Sat, Jun 29, 2013, at 10:33 AM, Kirk Terrell wrote:
> >>>> While trying to build a system using the latest version of the embedded
> >>>> GIT I ran into an issue at the beginning with the GMP build - I'ver
> >>>> tried twice. One time GMP compiled at the problem didn't manifest until
> >>>> gcc-static, where the it would build with the 64bit versions of GMP, MPC
> >>>> and MPFR. Based on some of the research i did it looks like GMP does a
> >>>> poor job of guessing processor, which leads to the wrong ABI. I don't
> >>>> know what i did different but the build failed, the following is a
> >>>> partial listing of the output:
> >>>>
> >>>>
> >>>> checking build system type... atom-pc-linux-gnu
> >>>> checking host system type... atom-pc-linux-gnu
> >>>
> >>> Is 'atom-pc-linux-gnu' a valid triplet?
> >>> If nothing else, I would think an embedded book build should be using
> >>> '-uclibc' as the ending portion of the triplet.  Unless I'm
> >>> misunderstanding something.
> >>>
> >>> If you are using 'atom-pc-linux-gnu', can you reproduce the issue using
> >>> a triplet of 'i686-pc-linux-uclibc' and report back?
> >>>
> >>>> checking for a BSD-compatible install... /usr/bin/install -c
> >>>> checking whether build environment is sane... yes
> >>>> checking for a thread-safe mkdir -p... /bin/mkdir -p
> >>>> checking for gawk... gawk
> >>>> checking whether make sets $(MAKE)... yes
> >>>> checking whether to enable maintainer-specific portions of Makefiles...
> >>>> no
> >>>> checking ABI=64
> >>>> checking compiler gcc -O2 -pedantic -fomit-frame-pointer -m64
> >>>> -fexceptions... yes
> >>>> checking compiler gcc -O2 -pedantic -fomit-frame-pointer -m64
> >>>> -fexceptions -mtune=atom... yes
> >>>> checking compiler gcc -O2 -pedantic -fomit-frame-pointer -m64
> >>>> -mtune=atom -fexceptions -march=atom... yes
> >>>> checking for gcc... gcc
> >>>> -------------------------
> >>>> -------------------------
> >>>> ../fib_table.h:4:1: warning: data definition has no type or storage
> >>>> class [enabled by default]
> >>>> ../fib_table.h:4:1: warning: type defaults to 'int' in declaration of
> >>>> 'Error' [enabled by default]
> >>>> ../fib_table.h:4:8: warning: type defaults to 'int' in declaration of
> >>>> 'error' [enabled by default]
> >>>> ../fib_table.h:4:20: error: expected '=', ',', ';', 'asm' or
> >>>> '__attribute__' before 'data'
> >>>> make[4]: *** [amd64check.lo] Error 1
> >>>> make[4]: Leaving directory
> >>>> `/opt/elfs20130613B.arm.little/sources/gmp-5.1.2/tests'
> >>>> make[3]: *** [check-am] Error 2
> >>>> make[3]: Leaving directory
> >>>> `/opt/elfs20130613B.arm.little/sources/gmp-5.1.2/tests'
> >>>> make[2]: *** [check-recursive] Error 1
> >>>> make[2]: Leaving directory
> >>>> `/opt/elfs20130613B.arm.little/sources/gmp-5.1.2/tests'
> >>>> make[1]: *** [check-recursive] Error 1
> >>>> make[1]: Leaving directory
> >>>> `/opt/elfs20130613B.arm.little/sources/gmp-5.1.2'
> >>>> make: *** [check] Error 2
> >>>> ------------------------------
> >>>> ----------------------------
> >>>> /usr/bin/ld: i386 architecture of input file `rand/.libs/randbui.o' is
> >>>> incompatible with i386:x86-64 output
> >>>> /usr/bin/ld: i386 architecture of input file `rand/.libs/randmui.o' is
> >>>> incompatible with i386:x86-64 output
> >>>> mpn/.libs/toom_interpolate_6pts.o: In function
> >>>> `__gmpn_toom_interpolate_6pts':
> >>>> toom_interpolate_6pts.c:(.text+0x2bc): undefined reference to
> >>>> `__gmpn_sublsh2_n_ip1'
> >>>> mpn/.libs/toom_interpolate_8pts.o: In function
> >>>> `__gmpn_toom_interpolate_8pts':
> >>>> toom_interpolate_8pts.c:(.text+0x3ca): undefined reference to
> >>>> `__gmpn_sublsh2_n_ip1'
> >>>> collect2: ld returned 1 exit status
> >>>> make[2]: *** [libgmp.la] Error 1
> >>>> make[2]: Leaving directory
> >>>> `/opt/elfs20130613B.arm.little/sources/gmp-5.1.2'
> >>>> make[1]: *** [install-recursive] Error 1
> >>>> make[1]: Leaving directory
> >>>> `/opt/elfs20130613B.arm.little/sources/gmp-5.1.2'
> >>>> make: *** [install] Error 2
> >>>> exitCode=2
> >>>>
> >>>>
> >>>> ---------------------------
> >>>>
> >>>> Some references that might be useful:
> >>>>
> >>>> http://gmplib.org/manual/Build-Options.html
> >>>>
> >>>> http://lists.gnu.org/archive/html/bug-standards/2012-01/msg00001.html
> >>>>
> >>>> http://lists.cross-lfs.org/htdig.cgi/clfs-support-cross-lfs.org/2009-September/000746.html
> >>>>
> >>>> --------------------
> >>>>
> >>>> i've built succesfully by seting ABI=32, not sure if this is the best
> >>>> solution.
> >>>
> >>> Based on [1] it seems it is.  And, somewhat good timing to catch this,
> >>> as armv8 is 64 bit now and we'll start seeing those real systems out
> >>> there, too :)
> >>>
> >>> [1]:http://gmplib.org/manual/ABI-and-ISA.html#ABI-and-ISA
> >>>
> >>> I've opened a bug [2] for this.
> >>>
> >>> [2]:http://trac.cross-lfs.org/ticket/925
> >>>
> >> I've built a complete system for vexpress-a9 running on QEMU using the
> >> book w/ the following three exceptions:
> >>
> >> 1)      added the --build=${CLFS_HOST} option when configuring GMP. For
> >> tracker 925 - I'm not setting the triplet, GMP is guessing the triplet
> >> for the host/build machine. It looks like some newer atom processors are
> >> 64 bit, mine is too old to be one of those.
> >
> > Ah, sorry, I should drink coffee *before* emailing :)
> > Now I see that GMP is picking build and host, not target.
> >
> > Are you building on a multilib distribution?  I'm curious why, if you've
> > only got 32 bit abilities on your host, that GMP is even able to think
> > you have 64 bit.  Or am I still not understanding this issue?
> >
> >> 2)      Did not execute the second stage for gcc - I think I only need
> >> the
> >> second stage for building C++, or other, compilers?
> >
> > You'll need gcc-final if you want dynamic linking, I believe, plus for
> > GCC to know to use uClibc vs just the built-in newlib.
> > You should always build gcc-final.
> >
> >> 3)      Deselected networking/nslookup in busybox .
> >>
> >> for the build I used the following parameters:
> >>
> >> export CLFS_ARCH=arm
> >> export CLFS_ABI="aapcs-linux"
> >> export CLFS_HOST="i686-cross-linux-gnu"
> >> export CLFS_ENDIAN="little"
> >> export CLFS_ARM_MODE="arm"
> >> export CLFS_ARM_ARCH="armv7-a"
> >> export CLFS_FLOAT="soft"
> >> export CLFS_TARGET="armel-unknown-linux-uclibceabi"
> >> export CC="armel-unknown-linux-uclibceabi-gcc"
> >>
> >>
> >> I did not need the soft float patch ( Ticket #919)
> >> I did not have an issues w/ the .size directive ( Ticket #876/ Tracker
> >> #917)
> >
> > OK, good to know! :)
> >
> >> Here is an excerpt from the busybox output for the issues w/ nslookup.
> >>
> >> networking/lib.a(nslookup.o): In function `nslookup_main':
> >> nslookup.c:(.text.nslookup_main+0x2c): undefined reference to
> >> `__res_init'
> >> nslookup.c:(.text.nslookup_main+0x54): undefined reference to
> >> `__res_state'
> >> nslookup.c:(.text.nslookup_main+0x78): undefined reference to
> >> `__res_state'
> >> nslookup.c:(.text.nslookup_main+0x8c): undefined reference to
> >> `__res_state'
> >> collect2: error: ld returned 1 exit status
> >> make: *** [busybox_unstripped] Error 1
> >>
> >> I have not had a chance to see if a tweak to the uClibc config file
> >> would address this.
> >
> > Is this without building gcc-final?  If so, I expect all sort of issues
> > without building a gcc-final.
> >
> > -Andrew
> > ____________________________________________________________
> > 4 Hormones Making Us Fat?
> > Learn how to control 4 hormones all skinny people have in balance.
> > http://thirdpartyoffers.netzero.net/TGL3365/51d1810c1dec810a2fecmp10duc
> >
> >
> Good Morning,
> 
> 
> 
> here is the results of the cpu flags and uname queries
> 
> kanj at primus-desktop:~$ grep flags /proc/cpuinfo
> flags           : fpu vme de tsc msr pae mce cx8 apic sep mtrr pge mca
> cmov pat 
> clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc 
> arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 
> cx16 xtpr pdcm movbe lahf_lm dtherm
> flags           : fpu vme de tsc msr pae mce cx8 apic sep mtrr pge mca
> cmov pat 
> clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc 
> arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 
> cx16 xtpr pdcm movbe lahf_lm dtherm
> kanj at primus-desktop:~$ uname -a
> Linux primus-desktop 3.2.0-30-generic-pae #48-Ubuntu SMP Fri Aug 24 
> 17:14:09 UTC 2012 i686 i686 i386 GNU/Linux
> kanj at primus-desktop:~$
> 
> I amn definitely running a 32 bit OS, but the lm flag on the second line 
> of the cpu flags implies 64 bit capability. According to the system 
> monitor the cpu is Intel® Atom™ CPU 230, which is 64 bit. :$
> 
>  From the links it looks like I'm not the first person to experience 
> this, and that GMP config.guess works differently than that of other 
> packages.
> 
> The following is an excerpt from gcc-static when the ABI is not set to 
> 32 for the GMP build (or set to a consistent build option):
> 
> checking for the correct version of gmp.h... yes
> checking for the correct version of mpfr.h... yes
> checking for the correct version of mpc.h... yes
> checking for the correct version of the gmp/mpfr/mpc libraries... no
> configure: error: Building GCC requires GMP 4.2+, MPFR 2.3.1+ and MPC 
> 0.8.0+.
> Try the --with-gmp, --with-mpfr and/or --with-mpc options to specify
> their locations.  Source code for these libraries can be found at
> their respective hosting sites as well as at
> 
> Of course the libraries are their they are just 64 bit, where the system 
> is looking for 32 bit - because we set the host to a 32 bit system?



More information about the Clfs-support mailing list