glibc-2.6.1 test errors

Athena lists at
Thu Oct 4 13:00:26 PDT 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:


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

EXAMPLE OF THE CONTENTS OF "test-float.out" (Truncated paste from bottom of 
the file)

Failure: Test: yn (10, 0.75) == -2133501638.90573424452445412893839236
 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

More information about the lfs-dev mailing list