[lfs-support] Installing Binutils and GCC after adjusting toolchain

Ken Moffat zarniwhoop at ntlworld.com
Wed Nov 14 10:50:33 PST 2012

On Wed, Nov 14, 2012 at 09:01:42AM +0100, Kaleb van Ingen Schenau wrote:
> Hello,
> I'm having a bit of a problem which is stopping me from continueing with
> LFS, after chapter 6.10 "Adjusting the Toolchain" i run the sanity check
> and all results come out as they are supposed to be according to the book.

 Hi, thanks for the prompt after the thread got hijacked :)  I'm not
at my best at the moment, and I haven't built for 32-bit in a very
long time.  But I'm now at my desktop instead of ssh'ing to the
server from a tty on the netbook, so let's see if I can offer
anything -

> But after i install Binutils MPFR, MPC, GMP, ZLIB, FILE and Gcc (not in
> that order)
 I will assume you followed the book's order :)
> the results of the test discribed in the install/compile
> section of GCC dont come out as they are supposed to be when i run:
> #echo 'main(){}' > dummy.c
> #cc dummy.c -v -Wl,--verbose &> dummy.log
> #readelf -l a.out | grep ': /lib'
> i get : [Requesting program interpreter: /lib/ld-linux.so.2] which is
> intented
> when i then run :
> #grep -o '/usr/lib.*/crt[1in].*succeeded' dummy.log
> it gives me:
> /usr/lib/crt1.o succeeded
> /usr/lib/crti.o succeeded
> /usr/lib/crtn.o succeeded
> instead of the intended:
> /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../crt1.o succeeded
> /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../crti.o succeeded
> /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../crtn.o succeeded
 Not wrong, just different :)  If you work out where these files are
(i.e. step up a directory for every '../') you will see that they
actually are in /usr/lib in both your result and what the book

 In my own 64-bit logs they have ... 4.7.1/../../../lib64/crt1.o
which implies that the book's version is expected on 32-bit.
> Then when i run :
> #grep -B4 '^ /usr/include' dummy.log
> it states:
> Ignoring nonexistent directory
> "/tools/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../i686-pc-linux-gnu/include
> Ignoring duplicate directory "/tools/include"
> #include "..." search starts here:
> #include <...> search starts here:
> /usr/include

 On 64-bit I get an 'Ignoring nonexistent directory' message,
followed by /usr/lib/gcc/.../include /usr/local/include
/usr/lib/gcc/.../include-fixed and /usr/include-fixed.

 So, you are not referencing the gcc /include and include-fixed
directories, nor /usr/local/include.

> Then when i run:
> #grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'
> SEARCH_DIR("/tools/i686-pc-linux-gnu/lib")
> SEARCH_DIR("/usr/lib")
> SEARCH_DIR("/lib");
> which is also not correct

 That seems to be correct - please compare it to the book - 3
matches, for /tools/i686-pc-linux-gnu, /usr/lib, /lib.  For this
part I don't see any error - please point it out if I'm wrong!
> #grep "/lib.*/libc.so.6 " dummy.log
> and
> #grep found dummy.log
> DO come up with the correct output
> This is the link to dummy.log:
> pastebin.com/dCjzz5yb
> Hope this helps and someone can shed some light on what part im messing up
> on between 6.10 and 6.17

 So, at the end of 6.10 everything was good, but now the include
path is wrong (doubled /tools/include, and only /usr/include) ?

 Are you doing something unusual ?  That probably includes building
on a virtual machine, using the package_users hint, and building on
mingw or whatever on windows.  Or using minimalist packages (dash,
busybox).  If this is a straight build linux from linux, did you
check the host against the Host System Requirements in the preface ?

 Sorry, I'm struggling to understand what has caused this

das eine Mal als Tragödie, das andere Mal als Farce

More information about the lfs-support mailing list