This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: glibc 2.3.2 for powerpc 405 & sim-full.c
- From: Dan Kegel <dank at kegel dot com>
- To: David Scidmore <dscidmore at xes-inc dot com>
- Cc: crossgcc at sources dot redhat dot com, GNU C Library <libc-alpha at sources dot redhat dot com>
- Date: Sat, 02 Aug 2003 15:55:29 -0700
- Subject: Re: glibc 2.3.2 for powerpc 405 & sim-full.c
- References: <05b901c35946$051bda00$1000340a@daves>
David Scidmore wrote:
I've been having trouble compiling glibc 2.3.2 for powerpc 405 processor
using Dan Kegels scripts as a template (with minor variations). After
reviewing a lot of messages from this list I came to the conclusion hat it
should just work if I use the switches, envirnoment variables, and compile
options used in the script. However, I consistenly kept getting errors due
to unresolved references while making libm. The references are all found in
a handfull of files from sysdeps/powerpc/nofpu (fegetexcept.c, fesetround.c
etc). The references were to three variables, all found in
sysdeps/powerpc/nofpu/sim-full.c. The files with the mission references were
all listed in the libm-support variable in math/Makefile. I eventually
resorted to adding sim-full.c to the libm-support variable in
sysdeps/powerpc/nofpu/Makefile (conditional on subdir being math). I'm a bit
of a novice, so I'm concerned that I may have fixed it in an inappropriate
way and will encounter problems downstream as a result.
You must have blinked :-)
My most recent release has a fix for this written by Daniel Jacobowitz:
http://www.kegel.com/crosstool/current/glibc-2.3.2-patches/glibc-2.3.2-without-fp.patch
It needs to be submitted to the glibc mailing list still,
but it seems to work fine for me.
I suspect you want to apply this rather than adding sim-full.c in,
but I wouldn't know. (Oh, sure, I have a spiffy build script,
but do I *understand* anything? Not really... one of these days,
maybe I'll take Karim and Bill's advice and learn this stuff more
thoroughly.)
Incidentally, glibc regression test results for this toolchain are at
http://www.kegel.com/crosstool/current/summaries/powerpc-405-linux-gnu-gcc-3.3-glibc-2.3.2.glibc.sum
The four floating-point failures are an accuracy thing,
and probably just mean I haven't read libm/README yet...
The only other failure I know of is linuxthreads/unload.
Haven't looked at why that's failing yet.
- Dan
--
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045