binutils-2.14 ch6 check DEJAGNU error
ken at kenmoffat.uklinux.net
Sat May 1 12:09:06 PDT 2004
On Sat, 1 May 2004, Andrew Sharp wrote:
> Dear all,
> I am stuck in building binutils-2.14 using book 5. I have tried unzipping the
> package again and rebuilding from scratch and recompiling, but it always ends
> the same when I make check...
> === ld tests ===
> Schedule of variations:
> Running target unix
> Running /sources/binutils-2.14/ld/testsuite/ld-bootstrap/bootstrap.exp ...
> FAIL: bootstrap with --static
> === ld Summary ===
> # of expected passes 191
> # of unexpected failures 1
> # of expected failures 1
> /sources/binutils-build/ld/ld-new 20030612
> make: *** [check-DEJAGNU] Error 1
Dejagnu-1.4.3 does this in certain error situations during the
toolchain tests. It used to do it to me on ppc until I applied some of
the dejagnu-1.4.3 patches from patches.linuxfromscratch.org. If it
comes to it, probably easiest to upgrade dejagnu to 1.4.4. But I think
it's a side-issue.
The real question is why this particular test fails. Are you on an
"unusual" architecture (i.e. nobody else has reported this particular
problem yet), or is it a weird host ? Google found me a link to
lfs-hackers (2.6 kernel, later glibc, shouldn't apply) and some Spanish
stuff about LFS that ended with a reference to
- but that is for chapter 5.
From memory there might be a file of test results in either the
binutils-2.14 or binutils-build trees, but I can't remember its name.
Unexpected failures in the tests aren't normally a showstopper in
themselves, but they can sometimes point to other errors. Have a look
at the log from when you configured this binutils (config.log, probably)
and see if anything "unexpected" shows up, such as a missing gettext.
If you can find something that you missed out, obviously go back and
build it. If not, and nobody else recognises this, I think going back
and upgrading dejagnu to 1.4.4 will let you carry on. Other weird and
new problems might follow if something you should have built earlier is
missing or broken.
The cause of broken things in /tools is managing to build them without
linking them to /tools/lib (the chapter 5 "locking in" step), but that
would prevent you getting this far. I've seen people with occasional
chapter 5 packages not linked correctly, possibly from missing something
when going back into chapter 5 after logging out from it, but never
really understood how it happened.
das eine Mal als Tragödie, das andere Mal als Farce
More information about the lfs-support