Make check again

Greg Schafer gschafer at zip.com.au
Wed Feb 12 20:23:06 PST 2003


On Wed, Feb 12, 2003 at 02:09:40AM +0100, Arjan Oosting wrote:
> Hi,
> 
> Some time ago i asked if anyone knew whether some results i've got after 
> running make check were bad. 
> (http://archive.linuxfromscratch.org/mail-archives/lfs-dev/2003/01/0966.html)
> I've done some build since then (without optimalization), and still got 
> some errors when running make check. I saw the scripts used by PureLFS 
> where doing make check, are these all running fine??

You need to understand that "make check" is not always meant to pass.
Failures often occur that are already known to the developers. They just may
not have gotten around to fixing those particular tests yet. Gcc is a
classic example. Glibc is a different story though. I refuse to install a
glibc that doesn't pass make check.

For gcc, the best policy is to run "make -k check"

> I will give a short report of my findings, maybe someone can comment on 
> them?
> 
> In chapter 5 fails the "make check" of
> grep 2.5:  Spencer bre test #16 failed
> 	FAIL: bre.sh

Did you notice the comment at the start of grep's make check that says:-

"Please, do not be alarmed if some of the tests failed.
Report them to <bug-gnu-utils at gnu.org>,
with the line number, the name of the file,
and grep version number 'grep --version'.
Make sure you have the word grep in the subject.
Thank You."

If you go and browse the bug-gnu-utils archive you'll see dozens of reports
of these failures.. I'm yet to look into this deeply but I don't think there
is too much to worry about..

> In chapter 6:
> gcc 3.2.2 fails the following tests
> 	=== libstdc++-v3 tests: ===
> 	XPASS: 22_locale/collate_byname.cc execution test
> 	XPASS: 22_locale/collate_members_char.cc execution test
> 	XPASS: 22_locale/collate_members_wchar_t.cc execution test
> 	XPASS: 22_locale/ctype_is_char.cc execution test
> 	XPASS: 22_locale/ctype_is_wchar_t.cc execution test
> 	XPASS: 22_locale/members.cc execution test
> 	XPASS: 22_locale/money_get_members_char.cc execution test
> 	XPASS: 22_locale/money_get_members_wchar_t.cc execution test
> 	XPASS: 22_locale/money_put_members_char.cc execution test
> 	XPASS: 22_locale/money_put_members_wchar_t.cc execution test
> 	XPASS: 22_locale/moneypunct_byname.cc execution test
> 	XPASS: 22_locale/moneypunct_members_char.cc execution test
> 	XPASS: 22_locale/moneypunct_members_wchar_t.cc execution test
> 	XPASS: 22_locale/num_get_members_char.cc execution test
> 	XPASS: 22_locale/num_get_members_wchar_t.cc execution test
> 	XPASS: 22_locale/num_put_members_char.cc execution test
> 	XPASS: 22_locale/num_put_members_wchar_t.cc execution test
> 	XPASS: 22_locale/numpunct_byname.cc execution test
> 	XPASS: 22_locale/numpunct_members_char.cc execution test
> 	XPASS: 22_locale/numpunct_members_wchar_t.cc execution test
> 	XPASS: 22_locale/time_get_members_char.cc execution test
> 	XPASS: 22_locale/time_get_members_wchar_t.cc execution test
> 	XPASS: 22_locale/time_put_members_char.cc execution test
> 	XPASS: 22_locale/time_put_members_wchar_t.cc execution test
> 	FAIL: 26_numerics/c99_classification_macros_c.cc (test for  excess 
> 	errors)

Those XPASS's are unexpected passes, not failures. The libstdc++ testsuite
apparently expects the locale model to be generic (--enable-clocale=generic)
however we use the superior (--enable-clocale=gnu) support from our C
library.

The 26_numerics failure has been there for ages. The libstdc++ developers
know about it but cannot fix it (for reasons I do not know).


> 	=== gcc tests ===
> 	FAIL: gcc.dg/format/c90-printf-1.c %s with NULL (test for warnings, 
> line 236)
> 	FAIL: gcc.dg/format/c90-printf-1.c (test for excess errors)

Those failures are probably due to your buggy expect package:-

http://gcc.gnu.org/ml/gcc/2002-08/msg01069.html


> 	=== g++ tests ===
> 	XPASS: g++.other/init5.C  Execution test

Unexpected pass (we use --enable-__cxa_atexit but not all gcc supported
systems have __cxa_atexit support in their C libs thus this test is not
always expected to pass)

> glibc 2.3.1 fails the test-lfs test (something with large filesystem 
> support):
> 	Timed out: killed the child process but it exited 0
> 	make[2]: *** [/tmp/build/glibc-build/io/test-lfs.out] Error 1
> 	make[2]: Leaving directory `/tmp/build/glibc-2.3.1/io'
> 	make[1]: *** [io/tests] Error 2
> 	make[1]: Leaving directory `/tmp/build/glibc-2.3.1'
> 	make: *** [check] Error 2

See above. This is a problem. Glibc's test suite should always pass.

> binutils 2.13.2.1 fails  in one ld-bootstrap test:
>         FAIL: bootstrap with --static

I noticed some failures due to lack of g++. This could be related.

> grep 2.5 fails in two tests:
>         Spencer test #55 failed
>         FAIL: spencer1.sh
> 
>         Options: Bond, test \#2 failed
>         FAIL: backref.sh

See above.

> perl 5.8.0 fails in 3 tests:
>         ext/Socket/Socket....................FAILED at test 2
>         lib/Net/hostent......................FAILED at test 2
>         lib/Net/t/hostname...................FAILED at test 1

Somebody already mentioned this. There are some networking files (which I
cannot recall right now) needed for these tests to pass.

> From al this tests i'm most worried by the results of binutils 
> (essential toolchain material) and grep. The results from the grep make 
> check seem to be dependent on which version of gcc u use. With gcc 
> 2.95.3 you get one failure (bre test #16), with gcc 3.2.* u get two 
> failures (spencer #55, bond #2).

AFAICT, your major worry is the glibc failure, and possibly the binutils
test. The gcc and binutils testsuites keep a log so you can peek at it and
see exactly what failed.

Greg
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list