toolchain readjustment methods

+Jan jonathan.oksman at
Sun Dec 13 09:53:40 PST 2009

Hey there lfs-dev!

I've been building a few systems on and off throughout the year.
Right now I'm sitting down and making one that I actually intend to
use for a while with the current svn.  I tend to deviate from the book
here and there usually anyway, but there was one difference that I
thought I'd mention here and see what you guys think because I found
it kind of useful.

A good chunk of time back, when the x86_64 stuff was still in the
works, I found I had to reset the chapter 6 process.  Usually when I
start on that chapter I make a backup of the toolchain so if something
catastrophic happens I can just blow everything away and unpack it,
starting fresh.  I forgot to do that though, and having made the book
directed changes to the specs file and moving ld to ld-old and linking
ld-new I had to go back and undo it.  Granted, not terribly hard

But the whole ld thing got me thinking about a faster way to switch
it.  So I made a few changes on my next build.

In chapter 5 on the second pass of binutils, after making and copying
ld-new to /tools/bin, I did the following:

# this might look familiar as it's identical to what is done
# in chapter 6 during the readjust phase
mv /tools/bin/{ld,ld-old}

# do the same for the -dumpmachine's ld
mv /tools/$($LFS_TGT-gcc -dumpmachine)/bin/{ld,ld-old}

# symbolic link to ld-old
ln -sv ld-old /tools/bin/ld

# link the -dumpmachine's ld to /tools/bin
ln -sv /tools/bin/ld /tools/$($LFS_TGT-gcc -dumpmachine)/bin/ld

Then in chapter 6 adjusting the dynamic linker can be done in one
command, which was the purpose for the changes:

ln -fsv ld-new /tools/bin/ld

I haven't had any problems using this method for the past half a year,
but I wonder how it'll stand up to a multilib setup.  I suspect
there'll be more problems there (or maybe just more changes), but I
won't be able to give it a shot until the new year.

Any thoughts on whether this is a good idea or a horrible practice?  I
couldn't see the harm in it since it does everything that is normally
done by the book, just in a slightly different fashion.


More information about the lfs-dev mailing list