[lfs-support] coreutils (lfs-7.0, section 6.23)

Qrux qrux.qed at gmail.com
Thu Jan 12 21:45:10 PST 2012


Ran the test suite for coreutils:

====
root:/scripts# grep -i fail src/coreutils-8.14/gnulib-tests/test-suite.log
1 of 270 tests failed.  (24 tests were not run).  
FAIL: test-parse-datetime (exit: 134)
test-parse-datetime.c:142: assertion failed
====

That's just the grep output (for '-i fail') in case anyone was wondering if there's more output.

Is this failure a show-stopper?  Or, can it be safely "ignored" (e.g., a bad-but-unavoidable host system)?

* * *

On the issue of failed tests (particularly in gcc & glibc), I've written some wrappers around those compilations, and do something like:

	cat test-summary | grep "sources" | egrep -v "known-fail-test-1|known-fail-test-2" | wc -l

Which basically scans the test summary files for the failed source files, and excludes the files/tests that are known (e.g., libmudflap, etc).  Then, it counts the lines with the intention of aborting if there are any lines found OTHER than the "sort-of-expected" failures.  I feel this is a reasonable approach for most, since we're mostly not gcc/glibc devs, and the test failures would be hard to evaluate.  Which is to say, I'm assuming that if the book lists these errors, we may as well exclude them from consideration.

For the gcc tests, I've scanned through a few other summaries from the GCC status pages, and removed some badly offending ones that seem to fail on lots of platforms.

For glibc, I just use the suggested "ignore" list in the book.

Do you feel this is a reasonable approach; if so, does this merit inclusion in the book itself?  Something like this:

==== glibc ====
#
# Well, GLIBC will have errors, so we turn bash error-
# handling off...
#
set +e
make -k check 2>&1 | tee glibc-check-log
set -e
#
# Now, turn bash error-handling back on, and check for
# the specific errors that are common.  If we find any
# other errors, then FAIL; otherwise, PASS.
#
__GLIBC_TEST_ERROR_COUNT=$(grep Error glibc-check-log | grep sources | egrep -v "posix/annexc|nptl/tst-clock2|nptl/tst-attr3|rt/tst-cpuclock2|misc/tst-writev|elf/check-textrel|nptl/tst-getpid2|stdio-common/bug22|posix/bug-regex32" | wc -l)

if [ 0 -ne $__GLIBC_TEST_ERROR_COUNT ] ; then
        grep Error glibc-check-log | grep sources
        false
fi
====

==== gcc ====
#
# GCC has a lot of tests, and some very complex ones can fail.
#
set +e
make -k check
set -e
../gcc-4.6.1/contrib/test_summary > ~/gcc-4.6.1-test_summary-LFS-$(date '+%Y%m%d_%H%M%S')

__GCC_FAIL_COUNT=$(../gcc-4.6.1/contrib/test_summary | grep FAIL | wc -l)
__GCC_OKAY_FAIL_COUNT=$(../gcc-4.6.1/contrib/test_summary | grep FAIL | egrep -v
 "gcc.c-torture/compile/limits-exprparen.c|libmudflap.c/pass49-frag.c" | wc -l)

if [ 0 -lt $__GCC_OKAY_FAIL_COUNT ] ; then        ../gcc-4.6.1/contrib/test_summary | grep FAIL
        echo "GCC testing failed; aborting"
        false
elif [ 0 -lt $__GCC_FAIL_COUNT ] ; then
        ../gcc-4.6.1/contrib/test_summary | grep FAIL
        echo "GCC testing had some failures, but these might be okay; continuing anyway..."
fi
====

	Q

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-support/attachments/20120112/07382c13/attachment.html>


More information about the lfs-support mailing list