glibc-2.6.1 test errors
Athena
lists at vega.uk.net
Thu Oct 4 14:00:26 MDT 2007
Hello List
I would really appreciate it if somebody would be able to help me with a
little problem which I'm having with glibc-2.6.1 make check on the current
LFS-DEV. I chatted to somebody on #lfs-support last night and they suggested
that I post my problem to this list.
So here goes....
I'm currently building a new LFS system using Version SVN-20070926. My host
system is a LFS-dev built about 8 months ago. Core components of my host
system are as follows:
gcc-4.1.1
glibc-2.5.
Binutils-2.17
linux-2.6.22.1
My host system was built against kernel-2.6.20 headers and my system CPU is a
Genuine Intel Prescott 3.2GH (Intel ID 540) running a little hot during
compiles (65C)
I have successfully completed chap5 without problem however in chap6 I am
experiencing problems with glibc-2.6.1. All compiles fine however when i run
make check I get the following errors. I must admit that i did not run make
check for glibc during chap5 :-( Maybe i should!
OUTPUT FROM "grep Error glibc-check-log"
sunrpc/rpc/pmap_rmt.h sunrpc/rpc/rpc.h sunrpc/rpc/rpc_des.h
sunrpc/rpc/rpc_msg.h sunrpc/rpc/svc.h sunrpc/rpc/svc_auth.h
sunrpc/rpc/types.h sunrpc/rpc/xdr.h sunrpc/rpcsvc/bootparam.h
sysvipc/sys/ipc.h sysvipc/sys/msg.h sysvipc/sys/sem.h sysvipc/sys/shm.h
termios/termios.h termios/sys/termios.h termios/sys/ttychars.h time/time.h
time/sys/time.h time/sys/timeb.h wcsmbs/wchar.h wctype/wctype.h
> /sources/build/glibc-build3/begin-end-check.out
make[1]: Target `check' not remade because of errors.
make[1]: Leaving directory `/sources/build/glibc-2.6.1'
make: *** [check] Error 2
root:/sources/build/glibc-build3# grep Error glibc-check-log
make[2]: *** [/sources/build/glibc-build3/math/test-float.out] Error 1
make[2]: *** [/sources/build/glibc-build3/math/test-double.out] Error 1
make[2]: *** [/sources/build/glibc-build3/math/test-ldouble.out] Error 1
make[2]: *** [/sources/build/glibc-build3/math/test-ildoubl.out] Error 1
make[2]: *** [/sources/build/glibc-build3/math/test-ifloat.out] Error 1
make[2]: *** [/sources/build/glibc-build3/math/test-idouble.out] Error 1
make[1]: *** [math/tests] Error 2
make[2]: [/sources/build/glibc-build3/posix/annexc.out] Error 1 (ignored)
make[2]: *** [/sources/build/glibc-build3/nptl/tst-attr3.out] Error 1
make[1]: *** [nptl/tests] Error 2
make[2]: *** [/sources/build/glibc-build3/debug/tst-chk3.out] Error 1
make[2]: *** [/sources/build/glibc-build3/debug/tst-lfschk3.out] Error 1
make[1]: *** [debug/tests] Error 2
make[1]: *** [/sources/build/glibc-build3/c++-types-check.out] Error 1
make: *** [check] Error 2
root:/sources/build/glibc-build3#
EXAMPLE OF THE CONTENTS OF "test-float.out" (Truncated paste from bottom of
the file)
Failure: Test: yn (10, 0.75) == -2133501638.90573424452445412893839236
Result:
is: -2.13350163890573453903e+09 -0x1.fcaa9b1b9f78e0000000p+30
should be: -2.13350163890573430061e+09 -0x1.fcaa9b1b9f78d0000000p+30
difference: 2.38418579101562500000e-07 0x1.00000000000000000000p-22
ulp : 1.0000
max.ulp : 0.0000
Maximal error of `yn'
is : 3 ulp
accepted: 2 ulp
Test suite completed:
2969 test cases plus 2600 tests for exception flags executed.
15 errors occurred.
Initially I started building chap6 using some “slightly” aggressive
optimization flags but when I ran into the make check errors i restarted
chap6 using the default optimization flags, however I still get errors.
Interestingly when i drop the optimization the error count increases for the
math tests. For example test-double.out drops to 4 errors and the precision
improves. IE: the last three digits of the long floats are different. Lower
optimization seems to make this problem worse?
Not wanting to flood this mailing list with potentially unneeded data I have
only posted the contents (part) of one of the *.out files. If you can help
and want to see the contents the rest of these files then please ask and I'll
post them. There isn't much info in them, just a few lines!
It may be my experience level but I suspect that I only need to be concerned
about the math errors, would this assumption be correct?
Anyway, again, i would be very appreciative of any help anyone could offer.
Many Thanks
Athena
More information about the lfs-dev
mailing list