Bill Hart wrote:
Yes, it looks like you are right. I've added it to the MPIR todo list
to fix this in our configure.
Thanks. Let us know when an upstream patch is available.
(The easiest work-around for the Sage spkg is perhaps just unsetting ABI
if config.guess matches core-*.)
Not sure which code paths should be selected for the Intel Core (on
32-bit systems at least "x86"), and whether other CPUs are missing
(besides the Pentium4 Prescott, as mentioned).
It is btw reproducible on other (capable, x86/x86_64) systems:
$ ../mpir-2.6.0/configure -v --host=core-pc-linux-gnu
...
checking ABI=standard
checking compiler core-pc-linux-gnu-gcc -O2 ... no
checking compiler gcc -O2 ... yes
checking for core-pc-linux-gnu-gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
...
using ABI="standard"
CC="gcc -std=gnu99"
CFLAGS="-O2"
CPPFLAGS=""
MPN_PATH=" generic"
...
(Note the MPN path.)
$ ../mpir-2.6.0/configure -v --host=core-pc-linux-gnu ABI=32
configure: WARNING: if you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used
checking build system type... bobcat-unknown-linux-gnu
checking host system type... core-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for core-pc-linux-gnu-strip... no
checking for strip... strip
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
configure: error: ABI=32 is not among the following valid choices: standard
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.
Well, we use it when building the Sage binary distributions, too, but
people are encouraged to build from source anyway... (Still many users
seem to prefer just grabbing these, unfortunately.)
-leif
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.
--
() 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.
