Yes, it looks like you are right. I've added it to the MPIR todo list to fix this in our configure.
Thanks for the report and the analysis. As for fat binary, sure, if the user requests it, no problem. I don't warrant it'll work on arbitrary systems though. I just thought this was the default for any Sage build on a 32 bit x86, which would be wrong. Bill. On 24 February 2013 17:37, leif <not.rea...@online.de> wrote: > Bill Hart wrote: >> >> Is it passing --enable-fat to MPIR's configure? If it is, then it >> shouldn't be. > > > If SAGE_FAT_BINARY=yes (set by the user, on Linux x86/x86_64 only IIRC). > Why shouldn't we? > > > But the real problem here seems to be an upstream (i.e., MPIR) bug: > > While config.guess yields core-pc-linux-gnu on the failing system, > 'core[-*]' isn't handled by MPIR's configure (such that abilist finally > contains only the dummy value, not '32', which we request): > > > ... > > # abilist needs to be non-empty, "standard" is just a generic name here > abilist="standard" > > ... > > case $host in # from config.guess (Sage doesn't configure with --host=... > or the like) > > ... > > # AMD and Intel x86 configurations, including AMD64 > # > # Rumour has it gcc -O2 used to give worse register allocation than just > # -O, but lets assume that's no longer true. > # > # -m32 forces 32-bit mode on a bi-arch 32/64 amd64 build of gcc. -m64 is > # the default in such a build (we think), so -m32 is essential for ABI=32. > # This is, of course, done for any $host_cpu, not just x86_64, so we can > # get such a gcc into the right mode to cross-compile to say i486-*-*. > # > # -m32 is not available in gcc 2.95 and earlier, hence cflags_maybe to use > # it when it works. We check sizeof(long)==4 to ensure we get the right > # mode, in case -m32 has failed not because it's an old gcc, but because > # it's a dual 32/64-bit gcc without a 32-bit libc, or whatever. > # > i?86*-*-* | k[5-8]*-*-* | pentium*-*-* | athlon-*-* | viac3*-*-* | > x86_64-*-* | netburst-*-* | netburstlahf-*-* | k8-*-* | k10-*-* | k102-*-* | > k103-*-* | core2-*-* | penryn-*-* | nehalem-*-* | westmere-*-* | > sandybridge-*-* | atom-*-* | nano-*-* | bobcat-*-* | bulldozer-*-*) > abilist="32" > cclist="gcc icc cc" > gcc_cflags="-O2 $fomit_frame_pointer" > case $host in > *-*-linux-gnu) > gcc_32_ldflags="-Wl,-z,noexecstack" ;; > esac > gcc_32_cflags_maybe="-m32" > icc_cflags="-no-gcc" > icc_cflags_optlist="opt" > icc_cflags_opt="-O3 -O2 -O1" > any_32_testlist="sizeof-long-4" > CALLING_CONVENTIONS_OBJS='x86call.lo x86check$U.lo' > > ... > > case $host_cpu in > i386*) path="x86/i386 x86" ;; > i486*) path="x86/i486 x86" ;; > i586 | pentium) path="x86/pentium x86" ;; > pentiummmx) path="x86/pentium/mmx x86/pentium x86" ;; > i686 | pentiumpro) path="x86/p6 x86" ;; > pentium2) path="x86/p6/mmx x86/p6 x86" ;; > pentium3) path="x86/p6/p3mmx x86/p6/mmx x86/p6 x86";; > k6[23]) path="x86/k6/k62mmx x86/k6/mmx x86/k6 x86" ;; > k6) path="x86/k6/mmx x86/k6 x86" ;; > athlon | k7 | x86_64 | atom) path="x86/k7/mmx x86/k7 x86" ;; > k102 | k103 | bulldozer) path="x86/k7/mmx/k8/k10/k102 > x86/k7/mmx/k8/k10 x86/k7/mmx/k8 x86/k7/mmx x86/k7 x86" ;; > k10) path="x86/k7/mmx/k8/k10 x86/k7/mmx/k8 > x86/k7/mmx x86/k7 x86" ;; > k8 | bobcat) path="x86/k7/mmx/k8 x86/k7/mmx x86/k7 x86" > ;; > core2 | penryn) path="x86/core2 x86" ;; > i786 | pentium4) path="x86/pentium4/sse2 x86/pentium4/mmx > x86/pentium4 x86" ;; > nehalem | westmere | sandybridge) path="x86/nehalem x86" ;; > prescott | netburst | netburstlahf) path="x86/pentium4/sse2 > x86/pentium4/mmx x86/pentium4 x86" ;; > # VIA/Centaur processors, sold as CyrixIII and C3. > nano | viac32) path="x86/p6/p3mmx x86/p6/mmx x86/p6 x86";; > viac3*) path="x86/pentium/mmx x86/pentium x86";; > *) path="x86" ;; > esac > > ... > > > (There are more case distinctions not matching 'core[-*]'. Looks like > 'prescott-*' was also missing in the /outer/ pattern, while it is used in > some inner ones.) > > > -leif > > > > >> On 24 February 2013 15:37, leif <not.rea...@online.de> wrote: >>> >>> Bill Hart wrote: >>>> >>>> >>>> Is it really trying to build a fat binary? I doubt that will work very >>>> many places. The fat binary support is there for binary builders to >>>> build binaries for multiple users, not for users to build >>>> binaries themselves. >>>> >>>> I doubt the fat binary option is compatible with many of the other >>>> options either. >>> >>> >>> >>> >>> Well, this seems to be again someone running a 32-bit OS on a 64-bit CPU >>> (core-pc-linux-gnu according to the configure output). >>> >>> I recall we explicitly had to set ABI=32 (hence added it to Sage's >>> spkg-install script) on such systems a while ago... (i.e., for MPIR >>> 2.4.0) >>> >>> Not sure why ABI="standard" (meaning what on x86/x86_64?) is required >>> here. >>> (The C compiler, some GCC 4.7.2, is configured to build 32-bit binaries >>> by >>> default, but also with --enable-targets=all.) >>> >>> >>> (I don't think --enable-fat is causing the problem.) >>> >>> >>> -leif >>> >>> >>> >>>> On Sunday, 24 February 2013, Jean-Pierre Flori wrote: >>>> >>>> This was reported here: >>>> https://groups.google.com/d/topic/sage-devel/9hpOtZYu8kI/discussion >>>> >>>> Also see #14172 >>>> >>>> Apparently MPIR does not like the ABI=32 var (???) but prefers >>>> ABI=standard. > > > -- > () The ASCII Ribbon Campaign > /\ Help Cure HTML E-Mail > > -- > You received this message because you are subscribed to the Google Groups > "mpir-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to mpir-devel+unsubscr...@googlegroups.com. > To post to this group, send email to mpir-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/mpir-devel?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
