Chapter 6 building against /tools still?

Simon Geard delgarde at
Thu Nov 13 23:44:14 PST 2008

On Thu, 2008-11-13 at 20:44 +0000, Ken Moffat wrote:
> We've had a certain amount of movement in the build order to catch
> things which were hard-coding /tools/bin into scripts.  A quick test
> of my own first build of 6.4-rc1 looks clean for that.

Just checked - the build I'm using is SVN-20081031. Going by the
changelog, that should be basically the same as 6.4-rc1.

> In bison, did you use the YYENABLE_NLS define for the first build ?
> If you did, any recollection of *how* it failed ?

Yes, it was built with that flag, as per the book.

The package that failed with bison problems was libIDL, but looking a
bit further, I think the bison installation is just plain broken. On
pretty much any valid input file (no matter how trivial), it exits with
status 141. If I rebuild bison, it works fine, presumably as it's now
linked to the correct libraries (as it no longer contains debug symbols
for /tools)

> For /tools/include: ouch!  Yes, agreed, and they are indeed
> debug symbols, which get removed if you run strip --strip-unneeded.
> Cc'ing to -dev for possible discussion, I've no idea if we can get
> rid of these references without stripping them and without
> rebuilding them.

My concern isn't that there are debug symbols referencing /tools - my
concern is that they're almost certainly a sign that things are being
linked against the wrong binaries, causing things like bison to fail.

As I said, I'm assuming this problem is caused by something I've done
wrong, causing Chapter 6 to favor /tools libraries and executables when
it shouldn't. I just can't see quite why.

-------------- 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