LFS-6.6 test error explanations
zarniwhoop73 at googlemail.com
Mon Mar 1 19:03:11 PST 2010
On 1 March 2010 23:36, Bruce Dubbs <bruce.dubbs at gmail.com> wrote:
> I've been analyzing the test errors found when I was building LFS-6.6.
> The logs are at
> This is a summary:
Thanks for this, it confirms and explains some of what I've found
in my own x86_64 build.
> annexc - long time errors that can be ignored.
> tst-cpuclock2 - this seems to be triggered by a setting in the
> kernel for cpu-scaling. That option is not needed on desktops, but it
> is set by default. It requires, by default, a user application to
> change cpu frequencies, but there are other options in the kernel. I
> think it can be ignored.
I didn't see this, but this build is on my one machine which
*doesn't* use frequency scaling. I think I've seen it on the
> pr34999.c - These do not build properly in the test suite. I found
> an entry in the bug tracker that this has been fixed for gcc-4.5.
Same here, thanks for the explanation
> libmudflap.c++/pass41-frag.cxx - This should be fixed in gcc-4.5 also.
Ditto - it's been broken for *ages*
> aclocal5.test. I couldn't track this down, but it seemed to pass and
> fail on my system intermittently. It passes all the time in a 32-bit
Didn't see this, but maybe I was lucky this time.
> stackoverflow2 - This appears ot be a kernel issue. I was building
> using lfs-6.5 (kernel 18.104.22.168) and getting the failure. It seems to be
> fixed when rebuilding on a 22.214.171.124 kernel.
Didn't see this, running 2.6.33 and using the 126.96.36.199 headers.
> machine specific failures - These are corner cases that test specific
> 64-bit boundary conditions. They don't fail on a 32-bit system and do
> appear to show up differently on different hardware. The possibility of
> running into problems here is very, very small.
Again, thanks for the explanation, I had exactly the same results
> I don't know if these errors should go into the book, be put on a web
> page, or just left in the mail repository for people to find when
> searching. Putting details about all of them in the book seems to be
> overkill, but we do have a section in 6.9, Glibc-2.11.1 about glibc test
> errors and some general comments, including libmudflap, in 6.16,
> GCC-4.4.3. There is nothing in the automake or gawk sections of the book.
> -- Bruce
At the moment, I'm dubious about recording these unless they turn
out to be common. Then again, a few people seem to think that any
failure not specifically mentioned in the book is cause for concern.
Meanwhile, I've got a few of my own (in alphabetical order) :
Didn't keep any of the directories, and only looked at the logs
later. First the non-locale errors
failed 182: parallel test execution (autotest.at:1116)
FAIL: bootstrap with --static
FAIL: static preinit array
FAIL: static init array
FAIL: static fini array
FAIL: Could not link a static executable
- these are probably down to me, I get rid of static libs
(except in the toolchain), probably it wants something I've
moved out of the way. I've seen these before and they
don't concern me.
The usual messages about include/scsi/scsi.h
(userspace cannot call function or variable defined in the kernel)
What I found interesting was that _no_ test progs were left
running when I unmounted at the end of chapter 6 - usually
I have problems unmounting. OTOH...
When I went back in today to finish building the extras I
need (fcron, mailx, ntp, nfs, etc) I had an error message
that it couldn't set the en_GB.UTF-8 locale, which was
worrying.- the finished system is ok (all locales seem
present), but there seems to be something wrong in my
scripts because I had:
printf2.sub: multibyte character conversion failed
Test #6 F failed: Cosi tu ^[[01;31m^[[KČiš^[[m^[[KÍ...
Test #7 F failed: Cosi tu ^[[01;31m^[[KČiš^[[m^[[KÍ...
(ISTR fmbtest failing is not unexpected)
(these are testing case conversion (\u and \U)
for cyrillic d/D [ д/Д ]
Still, as with all tests, I try not to give them too much
After tragedy, and farce, "OMG poneys!"
More information about the lfs-dev