Re-evaluate the possible Glibc test failures with the current GCC and Glibc combinations

[gerard@…]

Certain tests that used to fail in the past may not be failing anymore today.

Recheck this, update the book accordingly.

[Jeremy Huntwork]

Well, with all the recent ICA done on the builds, I would think we have several sources of information to evaluate. Dan have you been keeping the glibc test-results of your recent builds? If not, can we perhaps start keeping those and analyzing them so we can update the text in the book before we release 6.2? Dan, Manuel, Ken - you guys in a position to help?

[manuel@…]

I hope to can finish soon the ICA/farce support into jhalfs to can do several builds this weekend, but the builds made until now looks very goods.

Only one Glibc failure on all builds:

make[2]: sources/glibc-build/posix/annexc.out Error 1 (ignored)

[dbn.lists@…]

I'm getting one failure in malloc/tst-calloc.out. I'm trying to pinpoint it now. This is on anduin (Athlon-XP 2100). I've never gotten this on my home box (P-III 500). Could be specific to Athlon. I'll keep investigating, but it's a bit over my head.

GCC gets one failure in gcc.c-torture plus libmudflap failures (well known). I'll try to investigate the first one.

FAIL: gcc.c-torture/compile/20001226-1.c  -O3 -fomit-frame-pointer  (test for excess errors)
FAIL: libmudflap.cth/pass40-frag.c execution test
FAIL: libmudflap.cth/pass40-frag.c output pattern test
FAIL: libmudflap.cth/pass40-frag.c (-O2) execution test
FAIL: libmudflap.cth/pass40-frag.c (-O2) output pattern test
FAIL: libmudflap.cth/pass40-frag.c (-O3) execution test
FAIL: libmudflap.cth/pass40-frag.c (-O3) output pattern test

ICA round 2 (with the pruning bug pointed out by Manuel removed) is now complete. Results are clean.

Logs with testing are here:

​http://anduin.linuxfromscratch.org/~dnicholson/lfs-alpha-20060408-reports/test-logs/

[manuel@…]

I keep having the same failure on all builds and rebuilds:

make[2]: /sources/glibc-build/posix/annexc.out Error 1 (ignored)

That is a well-known failure that look was fixes upstream in Junaury:

​http://sourceware.org/ml/libc-hacker/2006-01/msg00001.html

[archaic@…]

Manuel, read the next message. This fix wasn't accepted from what I read. Please run a test moving the -I stuff to the end. as per Ulrich's reply. If the test passes after 3 builds, then update the ticket.

[manuel@…]

OK. I'm starting now a ICA/farce build using this sed in chapter06 only:

sed -i 's/ -I.. / /;s/sysincludes)/& -I../' posix/Makefile

Tomorrow we will see if it fix the text and/or if the sed should be added to chapter05 also.

[manuel@…]

No luck :-/

I tried all possible combinations of placing the stuff in that line but in all cases I end having the test failure.

[dbn.lists@…]

Here's the actual upstream commit:

​http://sourceware.org/ml/glibc-cvs/2006-q1/msg00009.html

Actually, it looks like that fix is just to address reorganizing of header files. I've never gotten the output that Andreas Jaeger is referring to. Could be a different issue.

[manuel@…]

Running the posix/annexc binary by hand, I suspect that is allways will to fail. That binary is cheking headers files, with an output like this (only a fragment, and the output is identical running the binary without arguments, wjint the arguments used in the Makefile, or changing the arguments order):

macana@sandbox:~/sources/glibc-build/posix$ ./annexc The following identifiers will be ignored since the compiler defines them by default: i386 unix linux Tested files:

aio.h

• invalid macro `SIGPROF'
• invalid macro `CLK_TCK'
• invalid macro `SIGSTKFLT'
• invalid macro `F_EXLCK'
• invalid macro `SIGURG'
• invalid macro `SIGIO'
• invalid macro `SIGPOLL'
• invalid macro `O_NDELAY'
• invalid macro `SIGCLD'
• invalid macro `O_FSYNC'
• invalid macro `F_SHLCK'
• invalid macro `F_SETLKW64'
• invalid macro `SIGTRAP'

etc, etc, for a lot of headers...

[archaic@…]

Using an AMD XP 2400+, I can say that the warning about the test-double and test-idouble failures doesn't apply. At least I haven't seen them in a very long time. The only failure I get is with posix/annexc.out. This is in both chap5 and chap6. However, the host has always been LFS. I'm have an older dual P3 and Athlon 1.33 GHz I can run builds on. Do those qualify for what the book calls "not a relatively new genuine Intel or authentic AMD" or am is it referring to pre-Athlon and P2's. If we can't decipher it, it might be worth removing that snippet of text.

[archaic@…]

Using my Athlon MP 2600+ laptop from a udev_update host and from Debian stable (gcc-3.3.5, glibc-2.3.2, linux-2.6.8) I still get only posix/annexc.out errors in both chapters. This older host does produce a couple more failures in chapter 5 gcc, but everything in chapter 6 is clean (save for mudflap). I was hoping to test on an older Athlon 1.33GHz, but the hard drive appears to be dying, so it will take me a bit to get around to it.

[bdubbs@…]

On my Dell laptop (Intel), glibc only gives the annex.c errors.

gcc gives only the (now standard) six libmudflap failures. Actually, these really appear to be one error:

Running /sources/gcc-4.0.3/libmudflap/testsuite/libmudflap.cth/cthfrags.exp ...
FAIL: libmudflap.cth/pass40-frag.c execution test
FAIL: libmudflap.cth/pass40-frag.c output pattern test
FAIL: libmudflap.cth/pass40-frag.c (-O2) execution test
FAIL: libmudflap.cth/pass40-frag.c (-O2) output pattern test
FAIL: libmudflap.cth/pass40-frag.c (-O3) execution test
FAIL: libmudflap.cth/pass40-frag.c (-O3) output pattern test

If the execution fails, the pattern will fail too.

[alexander@…]

Glibc-2.3.6 fails math/test-{float,ifloat,double,idouble}.out from today's Debian Etch. It doesn't fail annexc. CPU info below:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 11
model name      : Intel(R) Celeron(TM) CPU                1200MHz
stepping        : 1
cpu MHz         : 1202.884
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse
bogomips        : 2408.80

The failures might be caused by an attempt to compile the thing for i486 (uname hack on the LiveCD).

[alexander@…]

Sorry for my previous comment:

make[5]: [/lfs-livecd/packages/glibc/glibc-build/posix/annexc.out] Error 1 (ignored)

[alexander@…]

The same math failures are also present when building for i486 on ums.usu.ru:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Pentium(R) 4 CPU 2.40GHz
stepping        : 7
cpu MHz         : 2392.751
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid
bogomips        : 4186.11

So I guess that the cause of these failures is "compiling for less-than-i686", not "compiling on non-Intel CPU".

[dbn.lists@…]

Processor is PIII 500 building SVN-20060619.

No failures in glibc, gcc or binutils besides annexc.out.

However, I've noticed that the glibc tests (especially nptl/) are touchy if there is any system load. I've gotten a couple intermittent failures when building on a non-idle box. For instance, on both anduin (athlon xp 2100) and my PIII, I've returned both test results that had errors and didn't using the exact same build techniques.

In particular, tst-clock2 in nptl/ for glibc has been known to fail often. I've gotten it both on anduin and at home, and it has come up a couple times a month on lfs-support. The build with clean results was done overnight at home when things were completely idle. This was using the same svn version of jhalfs. If I knew C, I'd try to diagnose it.

My suggestion would be to mention that tst-clock2 can be safely ignored (if it's the only failure), and that running the toolchain testsuites on an unloaded box may provide cleaner results.

[dnicholson@…]

I sent an email to Alexander asking him about the glibc math test failures w.r.t building for i486.

>> I will retest glibc without
>> the i486 cross-compilation now and mail you the result.
>
> Thanks.

It passed. I used the following system: LFS LiveCD 6.2-pre4 extracted to
a partition. CFLAGS were "-march=i686 -mtune=i686 -O2 -pipe", in order
to overcome the default (on the CD) optimization for i486.

So this is in line with the comment that's already there: "The math tests sometimes fail in other tests when running on systems where the CPU is not a relatively new genuine Intel or authentic AMD. Certain optimization settings are also known to be a factor here." Perhaps this should be changed a bit so that any mention of optimization flags is removed since the book clearly tells people not to optimize the toolchain.

[dnicholson@…]

From the results in this bug covering various Intel and AMD processors, I think this line is not accurate anymore on the Glibc page.

On at least i686 you can expect to see failures in the test-double and test-idouble math tests with gcc-4.0.3, as well as an expected (ignored) failure in posix/annexc. These two failures in the math tests appear to be harmless.

It should just mention that annexc.out is expected.

Also, it doesn't appear anyone is getting the gettext failures. I've never seen one.

I don't know if the atime failure is still relevant since I've never built on a file system with noatime.

I think the last point about old/slow hardware should be amended to include systems under heavy load. Or just make a new bullet about not doing the tests under heavy load.

I personally thing tst-clock2.out deserves mention. I've seen it on two hosts, although I now think it is very sensitive to load. Seems that tst-attr3 is fairly common, too. I've gotten that one myself. Here's a few others on lfs-support:

​http://linuxfromscratch.org/pipermail/lfs-support/2006-July/030999.html ​http://linuxfromscratch.org/pipermail/lfs-support/2006-June/030944.html ​http://linuxfromscratch.org/pipermail/lfs-support/2006-May/030763.html ​http://linuxfromscratch.org/pipermail/lfs-support/2006-May/030793.html ​http://linuxfromscratch.org/pipermail/lfs-support/2006-April/030421.html

Binutils: Everyone has gotten clean results.

GCC: Just the libmudflap failures. Although I've gotten a couple random failures in the aforementioned "high load" case.

[bdubbs@…]

Updated glibc text concerning potential test failures as described by comments in this ticket.

Fixed at revision 7673.