Chapter 6 building against /tools still?

Ken Moffat ken at linuxfromscratch.org
Fri Nov 14 07:59:51 PST 2008


On Fri, Nov 14, 2008 at 10:00:40PM +1300, Simon Geard wrote:
> On Fri, 2008-11-14 at 20:44 +1300, Simon Geard wrote:
> > 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.
> 
> Ok, I've been looking at the logs from a fresh build, got a few
> questions.
> 
> 1. Should Chapter 6 binutils be using /tools/i686-pc-linux-gnu/bin/ld as
> it's linker?
> 
> 2. Should Chapter 6 GMP (i.e the package after binutils) be
> using /tools/i686-pc-linux-gnu/bin/ld?
> 
> 3. Should Chapter 6 GCC be using the same linker?
> 
> It looks like all packages after GCC are using /usr/bin/ld, but I guess
> by then the damage is done? Seems to me that everything after the final
> binutils build ought to be using it...
> 
> Simon.

 I've just looked at my logs, and also at my logs from 6.3.  In each
case, what the configure script is looking for is

 checking for ld used by gcc... /tools/i686-pc-linux-gnu/bin/ld
                ^^^^^^^^^^^^^
 Until chapter 6 gcc is installed, we can only use the gcc in
/tools, with its ld.  Of course, between building glibc and
configuring binutils we adjust the toolchain, so /tools/bin/ld gets
moved to ld-old, and ld-new is moved to it.

 Before gcc-4.3 with its addition of gmp, the important question for
chapter 6 was always "does it _link_ against /tools ?".  If that is
still a sufficient test, this is what I'm getting from my first
build (untarred from backup, not chrooted to it).

ken at ac30 ~/build1 $ldd usr/lib/libgmp.so.3.4.4 
	linux-gate.so.1 =>  (0xffffe000)
	libc.so.6 => /lib/libc.so.6 (0xb7dbc000)
	/lib/ld-linux.so.2 (0xb7f31000)
ken at ac30 ~/build1 $

 I'm unsure if that question is still *sufficient* to determine
purity. ISTR various comments about fixincludes with gcc-4.3 on
-dev.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce



More information about the lfs-support mailing list