This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: glibc 2.3.2 for powerpc 405 & sim-full.c


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]