Yes it is certainly possible the old autotools we use does not know
about the new OpenSolaris on x86.
It is as you say, an autotools issue. However we can probably hack our
configure script. The problem we have with autotools is recent
versions just break the build on almost anything but linux. So we
deliberately use old versions of the tools so things build on commonly
used architectures.
Anyhow, here is the x86 configure options from MPIR:
# 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.
#
X86_PATTERN | X86_64_PATTERN)
abilist="32"
cclist="gcc icc cc"
gcc_cflags="-O2 $fomit_frame_pointer"
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'
# Currently yasm is only needed to build x86 assembly files on
some hosts
want_yasm="yes"
# Availability of rdtsc is checked at run-time.
SPEED_CYCLECOUNTER_OBJ=pentium.lo
case $host in
*-*-solaris* | *-*-sunos*)
# Note no -g, it disables all optimizations.
cc_cflags=
cc_cflags_optlist="opt arch cpu"
# SunOS cc doesn't know -xO4, fallback to -O2.
cc_cflags_opt="-xO4 -O2" ;;
esac
# gcc 2.7.2 only knows i386 and i486, using -m386 or -m486. These
# represent -mcpu= since -m486 doesn't generate 486 specific
insns.
# gcc 2.95 adds k6, pentium and pentiumpro, and takes -march= and -
mcpu=.
# gcc 3.0 adds athlon.
# gcc 3.1 adds k6-2, k6-3, pentium-mmx, pentium2, pentium3,
pentium4,
# athlon-tbird, athlon-4, athlon-xp, athlon-mp.
# gcc 3.2 adds winchip2.
# gcc 3.3 adds winchip-c6.
# gcc 3.3.1 from mandrake adds k8 and knows -mtune.
# gcc 3.4 adds c3, c3-2, k8, and deprecates -mcpu in favour of -
mtune.
#
# In gcc 2.95.[0123], -march=pentiumpro provoked a stack slot bug
in an
# old version of mpz/powm.c. Seems to be fine with the current
code, so
# no need for any restrictions on that option.
#
# -march=pentiumpro can fail if the assembler doesn't know "cmov"
# (eg. solaris 2.8 native "as"), so always have -march=pentium
after
# that as a fallback.
#
# -march=pentium4 and -march=k8 enable SSE2 instructions, which
may or
# may not be supported by the assembler and/or the OS, and is bad
in gcc
# prior to 3.3. The tests will reject these if no good, so
fallbacks
# like "-march=pentium4 -mno-sse2" are given to try also without
SSE2.
# Note the relevant -march types are listed in the optflags
handling
# below, be sure to update there if adding new types emitting
SSE2.
#
# -mtune is used at the start of each cpu option list to give
something
# gcc 3.4 will use, thereby avoiding warnings from -mcpu. -mcpu
forms
# are retained for use by prior gcc. For example pentium has
# "-mtune=pentium -mcpu=pentium ...", the -mtune is for 3.4 and
the
# -mcpu for prior. If there's a brand new choice in 3.4 for a
chip,
# like k8 for x86_64, then it can be the -mtune at the start, no
need to
# duplicate anything.
#
gcc_cflags_optlist="cpu arch"
case $host_cpu in
i386*)
gcc_cflags_cpu="-mtune=i386 -mcpu=i386 -m386"
gcc_cflags_arch="-march=i386"
;;
i486*)
gcc_cflags_cpu="-mtune=i486 -mcpu=i486 -m486"
gcc_cflags_arch="-march=i486"
;;
i586 | pentium)
gcc_cflags_cpu="-mtune=pentium -mcpu=pentium -m486"
gcc_cflags_arch="-march=pentium"
;;
pentiummmx)
gcc_cflags_cpu="-mtune=pentium-mmx -mcpu=pentium-mmx -
mcpu=pentium -m486"
gcc_cflags_arch="-march=pentium-mmx -march=pentium"
;;
i686 | pentiumpro)
gcc_cflags_cpu="-mtune=pentiumpro -mcpu=pentiumpro -mcpu=i486 -
m486"
gcc_cflags_arch="-march=pentiumpro -march=pentium"
;;
pentium2)
gcc_cflags_cpu="-mtune=pentium2 -mcpu=pentium2 -
mcpu=pentiumpro -mcpu=i486 -m486"
gcc_cflags_arch="-march=pentium2 -march=pentiumpro -
march=pentium"
;;
pentium3)
gcc_cflags_cpu="-mtune=pentium3 -mcpu=pentium3 -
mcpu=pentiumpro -mcpu=i486 -m486"
gcc_cflags_arch="-march=pentium3 -march=pentiumpro -
march=pentium"
;;
k6)
gcc_cflags_cpu="-mtune=k6 -mcpu=k6 -mcpu=i486 -m486"
gcc_cflags_arch="-march=k6"
;;
k62)
gcc_cflags_cpu="-mtune=k6-2 -mcpu=k6-2 -mcpu=k6 -mcpu=i486 -
m486"
gcc_cflags_arch="-march=k6-2 -march=k6"
;;
k63)
gcc_cflags_cpu="-mtune=k6-3 -mcpu=k6-3 -mcpu=k6 -mcpu=i486 -
m486"
gcc_cflags_arch="-march=k6-3 -march=k6"
;;
k7 | athlon)
# Athlon instruction costs are close to P6 (3 cycle load
latency,
# 4-6 cycle mul, 40 cycle div, pairable adc, etc) so if gcc
doesn't
# know athlon (eg. 2.95.2 doesn't) then fall back on
pentiumpro.
gcc_cflags_cpu="-mtune=athlon -mcpu=athlon -mcpu=pentiumpro -
mcpu=i486 -m486"
gcc_cflags_arch="-march=athlon -march=pentiumpro -
march=pentium"
;;
i786 | pentium4)
# pentiumpro is the primary fallback when gcc doens't know
pentium4.
# This gets us cmov to eliminate branches. Maybe "athlon"
would be
# a possibility on gcc 3.0.
#
gcc_cflags_cpu="-mtune=pentium4 -mcpu=pentium4 -
mcpu=pentiumpro -mcpu=i486 -m486"
gcc_cflags_arch="-march=pentium4 -march=pentium4~-mno-sse2 -
march=pentiumpro -march=pentium"
;;
prescott)
# prescott is defined for our purposes as 32 bit pentium4 with
SSE3
gcc_cflags_cpu="-mtune=prescott -mtune=pentium4 -mcpu=pentium4
-mcpu=pentiumpro -mcpu=i486 -m486"
gcc_cflags_arch="-march=prescott -march=pentium4~-mno-sse2 -
march=pentiumpro -march=pentium"
;;
netburst | netburstlahf)
# prescott is defined for our purposes as 32 bit pentium4 with
SSE3
gcc_cflags_cpu="-mtune=nocona -mtune=pentium4 -mcpu=pentium4 -
mcpu=pentiumpro -mcpu=i486 -m486"
gcc_cflags_arch="-march=nocona -march=pentium4~-mno-sse2 -
march=pentiumpro -march=pentium"
;;
viac32)
# Not sure of the best fallbacks here for -mcpu.
# c3-2 has sse and mmx, so pentium3 is good for -march.
gcc_cflags_cpu="-mtune=c3-2 -mcpu=c3-2 -mcpu=i486 -m486"
gcc_cflags_arch="-march=c3-2 -march=pentium3 -march=pentiumpro
-march=pentium"
;;
viac3*)
# Not sure of the best fallbacks here.
gcc_cflags_cpu="-mtune=c3 -mcpu=c3 -mcpu=i486 -m486"
gcc_cflags_arch="-march=c3 -march=pentium-mmx -march=pentium"
;;
x86_64 | k8 | k10 | atom)
gcc_cflags_cpu="-mtune=k8 -mcpu=athlon -mcpu=pentiumpro -
mcpu=i486 -m486"
gcc_cflags_arch="-march=k8 -march=k8~-mno-sse2 -march=athlon -
march=pentiumpro -march=pentium"
;;
core2 | penryn | nehalem)
gcc_cflags_cpu="-mtune=core2 -mtune=nocona -mtune=pentium3 -
mcpu=pentiumpro -mcpu=i486 -m486"
gcc_cflags_arch="-march=core2 -march=nocona -march=pentium3 -
march=pentiumpro -march=pentium"
;;
*)
gcc_cflags_cpu="-mtune=i486 -mcpu=i486 -m486"
gcc_cflags_arch="-march=i486"
;;
esac
case $host_cpu in
i386*) path="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" ;;
# we don't have any specific 32-bit code for opteron (x86_64),
the
# athlon code should be reasonable
athlon | k7 | x86_64 | k8 | k10 | atom) path="x86/k7/mmx x86/
k7 x86" ;;
i786 | pentium4 | core2 | penryn | nehalem) path="x86/pentium4/
sse2 x86/pentium4/mmx x86/pentium4 x86" ;;
prescott | netburst | netburstlahf) path="x86/pentium4/
sse2 x86/pentium4/mmx x86/pentium4 x86" ;;
# VIA/Centaur processors, sold as CyrixIII and C3.
viac32) path="x86/p6/p3mmx x86/p6/mmx x86/p6
x86";;
viac3*) path="x86/pentium/mmx x86/pentium
x86";;
*) path="x86" ;;
esac
# If the user asked for a fat build, override the path set above
if test $enable_fat = yes; then
gcc_cflags_cpu=""
gcc_cflags_arch=""
extra_functions="$extra_functions fat fat_entry"
path="x86/fat x86"
fat_path="x86 x86/fat x86/i486
x86/k6 x86/k6/mmx x86/k6/k62mmx
x86/k7 x86/k7/mmx
x86/pentium x86/pentium/mmx
x86/p6 x86/p6/mmx x86/p6/p3mmx
x86/pentium4 x86/pentium4/mmx x86/pentium4/sse2"
fat_functions="add_n addmul_1 copyd copyi
dive_1 diveby3 divebyBm1of divrem_1 divrem_euclidean_qr_1
divrem_euclidean_qr_2 gcd_1 lshift
mod_1 mod_34lsub1 mode1o mul_1 mul_basecase
pre_divrem_1 pre_mod_1 redc_basecase rshift
sqr_basecase sub_n submul_1 sumdiff_n"
fat_exclude=""
fat_thresholds="MUL_KARATSUBA_THRESHOLD MUL_TOOM3_THRESHOLD
SQR_KARATSUBA_THRESHOLD SQR_TOOM3_THRESHOLD"
fi
case $host in
X86_64_PATTERN)
abilist="64 32"
cclist_64="gcc cc"
gcc_64_cflags="-O2 -m64"
gcc_64_cflags_optlist="opt arch cpu"
SPEED_CYCLECOUNTER_OBJ_64=x86_64.lo
CALLING_CONVENTIONS_OBJS_64='x86_64call.lo x86_64check$U.lo'
cyclecounter_size_64=2
case $host in
*-*-solaris* | *-*-sunos*)
# Note no -g, it disables all optimizations.
cc_64_cflags="-m64"
cc_64_cflags_optlist="opt arch cpu"
# SunOS cc doesn't know -xO4, fallback to -O2.
cc_64_cflags_opt="-xO4 -O2" ;;
esac
case $host in
x86_64-*-*)
path_64="x86_64" ;;
netburst-*-*)
path_64="x86_64/netburst x86_64" ;;
netburstlahf-*-*)
path_64="x86_64/netburst/netburstlahf x86_64/netburst
x86_64" ;;
k8-*-*)
path_64="x86_64/k8 x86_64" ;;
k10-*-*)
path_64="x86_64/k8/k10 x86_64/k8 x86_64" ;;
core2-*-*)
path_64="x86_64/core2 x86_64" ;;
penryn-*-*)
path_64="x86_64/core2/penryn x86_64/core2 x86_64" ;;
nehalem-*-*)
path_64="x86_64/nehalem x86_64" ;;
atom-*-*)
path_64="x86_64/atom x86_64" ;;
esac
# If the user asked for a fat build, override the path set
above
if test $enable_fat = yes; then
gcc_64_cflags_cpu=""
gcc_64_cflags_arch=""
extra_functions_64="$extra_functions_64 fat fat_entry"
path_64="x86_64/fat x86_64"
fat_path_64="x86_64 x86_64/fat x86_64/netburst x86_64/
netburst/netburstlahf x86_64/k8 x86_64/k8/k10 x86_64/core2 x86_64/
core2/penryn x86_64/nehalem x86_64/atom"
fi
;;
esac
;;
You can see we do check if the OS is Solaris and do various things.
Perhaps we can force something in there, though I am uncertain what
can be overridden in autotools. A lot of (wrong) automatic behaviour
is hard to work around.
Bill.
On 16 July, 00:55, "Dr. David Kirkby" <david.kir...@onetel.net> wrote:
> Bill Hart wrote:
> > Here is the entire sparc configuration from MPIR:
>
> > *sparc*-*-*)
> > # sizeof(long)==4 or 8 is tested, to ensure we get the right ABI.
> > We've
>
> Hi Bill,
>
> The processor in Thommy's computer is is not SPARC - see the output I
> posted:
>
> Host system
> uname -a:
> SunOS bigblue 5.11 snv_101b i86pc i386 i86pc Solaris
>
> What I just noticed is the incorrect output from the configure script.
>
> checking for ld used by gcc -std=gnu99... ld
> checking if the linker (ld) is GNU ld... yes
>
> So the configure script seems to have decided that the linker is the GNU
> linker, which might explain why it sends GNU specific flags. But the way
> the compiler is configured, we see its built with the Sun linker, not
> the GNU one.
>
> Configured with: /builds2/sfwnv-gate/usr/src/cmd/gcc/gcc-3.4.3/configure
> --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as
> --with-ld=/usr/ccs/bin/ld --without-gnu-ld
> --enable-languages=c,c++,f77,objc --enable-shared
> Thread model: posix
> gcc version 3.4.3 (csl-sol210-3_4-20050802)
>
> The error message is clearly generated by the Sun linker too. Although I
> don't have my Solaris x86 laptop on, the error message from the linker
> is clearly the GNU one.
>
> Here's the output from my Sun linker (on SPARC not x86). I think you can
> see it is very similar (perhaps even identical) to the output from
> Thommy's computer x86 computer, and nothing like what you would get from
> the GNU linker.
>
> drkir...@kestrel:[~] $ ld -l
> ld: option requires an argument -- l
> usage: ld [-6:abc:d:e:f:h:il:mo:p:rstu:z:B:CD:F:GI:L:M:N:P:Q:R:S:VY:?]
> file(s)
> [-64] enforce a 64-bit link-edit
> [-a] create an absolute file
> [-b] do not do special PIC relocations in a.out
> [-B direct | nodirect]
> establish direct bindings, or inhibit direct
> binding
> to, the object being created
>
> So I think I can see why the problem probably occurs - the configure
> script has incorrectly determined the linker is the GNU one, when in
> fact is is the Sun linker.
>
> Could it be the configure script is using old versions of
> automake/autoconf, which are not fully aware of OpenSolaris on x86?
>
> Dave
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
