Chapter 6 building against /tools still?

Simon Geard delgarde at
Sun Nov 30 23:08:35 PST 2008

On Sun, 2008-11-30 at 21:46 +1300, Simon Geard wrote: 
> On Fri, 2008-11-28 at 23:59 +0100, Renaud Marquet wrote:
> > As gcc, glibc and binutils are all built with /tools/bin/gcc it's
> > obvious they contain debug information referencing /tools/...
> > 
> > Don't know why bison is, though. Maybe it's because gcc contains this
> > reference too. I just checked my system and it's the same (in fact,
> > almost every executable is referencing /tools in its debug information).
> > 
> > Anyway this should not lead to any runtime problem I think.
> That's what I hoped, but no, still broken. I think (not certain) it
> worked before I removed /tools, but now it fails with status 141 any
> time it's invoked on a valid input file...
> Can't think why bison would be different from anything else though. It's
> built after e2fsprogs and coreutils, and neither of those contain those
> debug symbols. But bison, built a bit later, does...

On closer inspection, I think I've found the problem. Bison doesn't
contain /tools debug symbols at all - what it does have is a hardcoded
reference to /tools/bin/m4, and sure enough, the proper install of m4
was being done after bison in my scripts. So the failure was probably
due to the inability to find m4 after I nuked /tools.

One other thing I wonder about, in the find 6.4 book. As I noted before,
one of my earlier problems was that libtool was ending up with hardcoded
references to /tools/bin/grep, which I corrected by moving grep to be
build a little earlier. However, the 6.4 book has grep built after
libtool, so I'm not sure what's going on there...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <>

More information about the lfs-support mailing list