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
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
