CLFS 1.1.0 Status

[Joe Ciccone]

Architecture	Builds	Testsuites	Other Tickets
i486		Needs to be Checked
i586	Yes	Needs to be Checked
i686	Yes	Logged & Acceptable
x86_64	Yes	Needs to be Checked
x86_64-64	Yes	Logged & Acceptable
Alpha	Yes	Needs to be Checked	#139
Sparc		Needs to be Checked
Sparc64	Yes	Needs to be Checked	#144 #149
Sparc64-64		Needs to be Checked	#144 #149
Mips (Little Endian)		Needs to be Checked
Mips64 (Little Endian)		Needs to be Checked
Mips64-64 (Little Endian)		Needs to be Checked
Mips (Big Endian)		Needs to be Checked
Mips64 (Big Endian)		Needs to be Checked
Mips64-64 (Big Endian)		Needs to be Checked
PPC	Yes	See comment by ken	#123
PPC64	Yes	See comment by ken

Tickets that effect the entire book: #146 #169 #151

Uploaded Testsuite Logs: ​http://cross-lfs.org/testsuite-logs/clfs-1.1.0/

[ken]

How do you want to detail the testsuites ? Based on current LFS, I expect a failure in one of the autofoo packages, for which they have a patch, 2 in grep (the headline number of failures can be treated as "expected" since the book doesn't support UTF-8), and 2 in texinfo (two of the tests fail if you don't have a working tex, two more skip). Maybe there are other minor failures too, and probably failures in the toolchain tests.

[ken]

The following (only) fail on powerpc ('ppc'): automake-1.10.1

FAIL: instsh2.test

That is the one that I assume is fixed by the patch in LFS, caused by running as root.

flex-2.5.34

Test test-c++-multiple-scanners FAILED.
Test test-pthread FAILED.

expected. Actually, I'm surprised to get any output, I think the poor formatting of the results confused me in my LFS results.

gcc-4.2.2

FAIL: gcc.dg/tree-ssa/loop-19.c scan-tree-dump-times MEM.(base: &|symbol: )a, 2
FAIL: gcc.dg/tree-ssa/loop-19.c scan-tree-dump-times MEM.(base: &|symbol: )c, 2
FAIL: g++.dg/other/unused1.C scan-assembler (string|ascii?)z?\t"class2("|\\\\000)

my previous build (end of December) failed horrendously here, I now think that my personal script didn't get on with util-linux-ng (specifically /dev/pts appeared not to be mounted, although /dev was bound - now fixed by a further bind mount, maybe the text after spawn ls is misplaced in both LFS and clfs and should be in gcc ? dunno.)

glibc-2.7 failed unexpectedly for

math/test-ldouble.out
math/test-ildoubl.out
crypt/sha512c-test.out
elf/check-localplt.out
}}

grep-2.5.3
{{{
FAIL: foad1.sh
FAIL: fmbtest.sh
FAIL: yesno.sh
}}}
 this is normal

texinfo-4.11
{{{
FAIL: dvipdf.test
FAIL: texi2dvi.test
}}}
 These two tests fail in the absence of a working tex

vim-7.1
{{{
test3 FAILED
}}}
 This always fails for me, I've no idea what it is doing, so YMMV.

 Other comments: I didn't notice when e2fsprogs stopped failing on ppc - maybe 1.40.4 is the first version.  I've seen a report (on lfs-dev) that 1.40.6 causes problems for grub, but both yaboot and lilo seem ok with all versions.

[ken]

Replying to ken:

The following (only) fail on powerpc ('ppc'): flex-2.5.34

Noticed the book has moved on to 2.5.35. A quick run of the testsuite for that shows all the tests (46) succeeded.

Perhaps I ought to mention that the build used the chroot method, but with true cross-compilation on i686.

[ken]

Belatedly, the ppc64 test results (the build itself was started on an i686, then chrooted; the finished desktop shows no issues).

Following showed failures:

automake-1.10.1 - instsh2.test, as I expect

binutils-2.18 - within ld, 10 instances of
ERROR: /building/binutils-2.18/ld/testsuite/ld-elfvsb/sh2.c: compilation failed
 - these are then reported as 20 unresolved testcases

flex : I was using a version of the book from before 2.5.35 went in.
 3 failures, the 'new' one was test-alloc-extra.
I've now built and tested 2.5.35, that passes all its testsuite.

gcc-4.2.2 (all messages, including XPASSes)
 g++
FAIL: g++.dg/other/unused1.C scan-assembler(string|ascii?)z?\\t"class2("|\\\\\\\\000)
 gcc
UNRESOLVED: gcc.c-torture/execute/mayalias-2.c execution,  -O3 -g 
FAIL: gcc.dg/tree-ssa/loop-19.c scan-tree-dump-times MEM.(base: &|symbol: )a, 2
FAIL: gcc.dg/tree-ssa/loop-19.c scan-tree-dump-times MEM.(base: &|symbol: )c, 2
XPASS: gcc.dg/tree-ssa/sra-2.c scan-tree-dump-times link_error 0
FAIL: gcc.target/powerpc/ppc-negeq0-1.c scan-assembler-not cntlzw
 (libgomp ok)
 libmudflap
FAIL: libmudflap.c/fail27-frag.c output pattern test
FAIL: libmudflap.c/fail27-frag.c (-static) output pattern test
FAIL: libmudflap.c/fail27-frag.c (-O2) output pattern test
FAIL: libmudflap.c/fail27-frag.c (-O3) output pattern test
 libstdc++
XPASS: 27_io/fpos/14320-1.cc execution test
glibc-2.7 32-bit had 5 unexpected failures
math/test-ldouble.out
math/test-ildoubl.out
resolv/tst-leaks.out
elf/check-textrel.out
elf/check-localplt.out

 I had to rerun that after the original build, because a fubar in my
scripts gave me an empty file.  So, I got to see the .out files:

testing long double (without inline functions)
Failure: Test: signgam for lgamma(-0) == -1
Result:
 is:         1
 should be:  -1

Test suite completed:
  4128 test cases plus 3367 tests for exception flags executed.
  1 errors occurred.

testing long double (inline functions)
Failure: Test: signgam for lgamma(-0) == -1
Result:
 is:         1
 should be:  -1

Test suite completed:
  4066 test cases plus 3305 tests for exception flags executed.
  1 errors occurred.

resolv/tst-leaks.out was empty

elf/check-textrel.out complains about 265 libraries which have a
segment that is executable and writable - I think that test doesn't
get run on regular ppc, because it cannot pass in the 32-bit ABI,
but now we are on ppc64 so it is 'expected' to pass (for the 64-bit
ABI, of course). 

elf/checklocalplt.out is a diff:
--- ../scripts/data/localplt-powerpc-linux-gnu.data     2007-08-07 06:36:08.000000000 +0100
+++ -   2008-03-13 20:27:45.775545000 +0000
@@ -1,7 +1,23 @@
 libc.so: _Unwind_Find_FDE
+libc.so: __signbitl
 libc.so: calloc
 libc.so: free
 libc.so: malloc
 libc.so: memalign
 libc.so: realloc
+libm.so: __fe_nomask_env
+libm.so: __signbitl
+libm.so: cosl
+libm.so: fegetexcept
+libm.so: fetestexcept
+libm.so: finitel
+libm.so: frexpl
+libm.so: ilogbl
+libm.so: ldexpl
+libm.so: logl
+libm.so: lroundl
 libm.so: matherr
+libm.so: nextafter
+libm.so: roundl
+libm.so: sinl
+libm.so: sqrtl

 Most of that means nothing to me.

glibc-2.7 64-bit 3 failures (test-ldoubl, test-ildoubl, checklocalplt)

grep-2.5.3 the 3 usual failures in foad1.sh, fmbtest.sh, yesno.sh
 
texinfo-4.11 the 2 failures I expect (dvipdf.test, texi2dvi.test)

vim-7.1 has the usual, impenetrable, test3 FAILED

[ken]

x86_64-64 testsuites, after changes r3908 and r3909:

glibc all ok (yes, annexc.out produces a message, but that's all)

automake fails inst2sh.test because we don't patch it

bash seems to be the usual whitespace and "don't run as root"

binutils all ok

gcc - for gcc itself, warnings about compilation failures in torture/fp-int-convert-float-128* which is presumably the 1 unresolved testcase for g++

FAIL: g++.dg/other/unused1.C scan-assembler (string|ascii?)z?\t"class2("|

000)

XPASS: g++.dg/tree-ssa/ivopts-1.C scan-tree-dump-not offset: -4B

XPASS: g++.dg/tree-ssa/ivopts-1.C scan-tree-dump-not &x\[5\]

for libstdc++

XPASS: 27_io/fpos/14320-1.cc execution test (yes, I know some people think XPASSes should be ignored!)

two failures in libmudflap

FAIL: libmudflap.c/fail8-frag.c (-static) output pattern test

FAIL: libmudflap.c/fail9-frag.c (-static) output pattern test

grep fails foad1.sh, fmbtest.sh, yesno.sh as expected

texinfo fails dvipdf.test and texi2dvi.test as expected

vim fails test3 as usual

All other testsuites completed without incident.

[ken]

Just for a laugh, on x86_64-64 I've updated the headers to 2.6.24.7, and the running kernel to the same plus some fixes extracted/backported by debian, with gcc-4.2.4. The "pure64" patch needs updating (as will the ppc64 multilib patch).

Gcc has the same problems with fp-int-convert-float-128*, but g++, libstdc++, libmudflap have no failures and no XPASSes.

I'll look at putting the kernel in this week, gcc-4.2.4 is encouraging but I'd like to see how it looks on ppc64 - I don't think the improved test results are actually worth a lot, I've still got "the evince problem", but other than that it seems as sound as the previous build.

[Joe Ciccone]

Added a link to the path of testsuite logs in the description.

[Joe Ciccone]

Uploaded x86_64-64 testsuite logs. I'm 99% sure that I got the exact same failures that ken got in his comment above. I put Logged & Acceptable in the description. These are the same tests that have been failging for a while. They don't seem to be affecting much.

I also updated the ticket numbers in the table that need to get resolved before the release.