Chapter 6 building against /tools still?

Simon Geard delgarde at ihug.co.nz
Fri Nov 28 02:52:09 PST 2008


On Thu, 2008-11-13 at 21:10 +1300, Simon Geard wrote:
> Hey, guys. Just finished a build of recent SVN (a week or two old),
> getting some problems on some of the BLFS packages. Tools like Bison
> aren't working properly, that sort of thing, and then I got one error
> message (can't remember what package it was on) complaining
> about /tools.
> 
> And yes, it looks to me like most of chapter 6 (including binutils and
> gcc) has been linked against libraries in /tools. Scripts like libtool
> have ended up with paths to /tools/bin/grep, and binaries
> like /usr/bin/gcc and the like contain references to /tools/include,
> which appear to be debug symbols.

A follow up to this - I've checked my scripts somewhat, and fixed a few
discrepancies between them and the 6.4 book, in particular a few chapter
6 packages out of order (resulting in the scripts referencing grep and
m4), and some issues with the building of gmp/mpfr/gcc in chapter 5.
This seems to have somewhat reduced the number of files containing debug
info referencing /tools/include, to the following:

# grep '/tools' /bin/* /sbin/* /usr/bin/* /usr/sbin/* /usr/lib/*  /lib/*
Binary file /sbin/ldconfig matches
Binary file /sbin/sln matches
Binary file /usr/bin/addr2line matches
Binary file /usr/bin/ar matches
Binary file /usr/bin/bison matches
Binary file /usr/bin/c++ matches
Binary file /usr/bin/cc matches
Binary file /usr/bin/c++filt matches
Binary file /usr/bin/cpp matches
Binary file /usr/bin/g++ matches
Binary file /usr/bin/gcc matches
Binary file /usr/bin/i686-pc-linux-gnu-c++ matches
Binary file /usr/bin/i686-pc-linux-gnu-g++ matches
Binary file /usr/bin/i686-pc-linux-gnu-gcc matches
Binary file /usr/bin/i686-pc-linux-gnu-gcc-4.3.2 matches
Binary file /usr/bin/nm matches
Binary file /usr/bin/objcopy matches
Binary file /usr/bin/objdump matches
Binary file /usr/bin/ranlib matches
Binary file /usr/bin/readelf matches
Binary file /usr/bin/size matches
Binary file /usr/bin/strings matches
Binary file /usr/bin/strip matches
Binary file /usr/sbin/zic matches
Binary file /usr/lib/libbfd-2.18.so matches
Binary file /usr/lib/libbfd.so matches
Binary file /usr/lib/libmpfr.a matches
Binary file /usr/lib/libmpfr.so matches
Binary file /usr/lib/libmpfr.so.1 matches
Binary file /usr/lib/libmpfr.so.1.1.2 matches
Binary file /usr/lib/libm.so matches
Binary file /usr/lib/librt.so matches
Binary file /lib/cpp matches
Binary file /lib/libm-2.8.so matches
Binary file /lib/libm.so.6 matches
Binary file /lib/libpthread-2.8.so matches
Binary file /lib/libpthread.so.0 matches
Binary file /lib/librt-2.8.so matches
Binary file /lib/librt.so.1 matches

Any particular reason why these files would be affected still? I note
almost all of them are from gcc, glibc, or binutils, which might make
some sense. Bison still stands out as an odd case though... it's one of
the earlier chapter 6 packages, but certainly not the first.

Simon.
-------------- 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: <http://lists.linuxfromscratch.org/pipermail/lfs-support/attachments/20081128/137964d6/attachment.sig>


More information about the lfs-support mailing list