Now that the new and final C libraries have been installed, it's time to adjust our toolchain again. We'll adjust it so that it will link any newly compiled program against these new libraries. This is in fact the same thing we did in the “Adjusting” phase in the beginning of the previous chapter, even though it looks like the reverse: then we guided the chain from the host's /{,usr/}lib to the new /tools/lib, now we guide it from that same /tools/lib to the LFS's /{,usr/}lib.
First we adjust the linker. For this we retained the source and build directories from the second pass over Binutils. Install the adjusted linker by running the following from within the binutils-build directory:
make -C ld INSTALL=/tools/bin/install install
![[Note]](../images/note.png) |
Note |
|---|---|
|
If you somehow missed the earlier warning to retain the Binutils source and build directories from the second pass in Chapter 5, or otherwise accidentally deleted them or just don't have access to them, don't worry, all is not lost. Just ignore the above command. The result will be that the next package, Binutils, will link against the C libraries in /tools rather than in /{,usr/}lib. This is not ideal, however, our testing has shown that the resulting Binutils program binaries should be identical. |
|
From now on every compiled program will link only against the libraries in /usr/lib and /lib. The extra INSTALL=/tools/bin/install is needed because the Makefile created during the second pass still contains the reference to /usr/bin/install, which we obviously haven't installed yet. Some host distributions contain a ginstall symbolic link which takes precedence in the Makefile and thus can cause a problem here. The above command takes care of this also.
You can now remove the Binutils source and build directories.
The next thing to do is to amend our GCC specs file so that it points to the new dynamic linker. Just like earlier on, we use a sed to accomplish this:
SPECFILE=/tools/lib/gcc-lib/*/*/specs &&
sed -e 's@ /tools/lib/ld-linux.so.2@ /lib/ld-linux.so.2@g' \
$SPECFILE > newspecfile &&
mv -f newspecfile $SPECFILE &&
unset SPECFILE
Again, cutting and pasting the above is recommended. And just like before, it is a good idea to visually inspect the specs file to verify the intended change was actually made.
![[Important]](../images/important.png) |
Important |
|---|---|
|
If you are working on a platform where the name of the dynamic linker is something other than ld-linux.so.2, you must substitute ld-linux.so.2 with the name of your platform's dynamic linker in the above commands. Refer back to the section called “Toolchain technical notes” if necessary. |
|
![[Caution]](../images/caution.png) |
Caution |
|---|---|
|
It is imperative at this point to stop and ensure that the basic functions (compiling and linking) of the adjusted toolchain are working as expected. For this we are going to perform a simple sanity check:
echo 'main(){}' > dummy.c
cc dummy.c
readelf -l a.out | grep ': /lib'
If everything is working correctly, there should be no errors, and the output of the last command will be (allowing for platform specific differences in dynamic linker name): [Requesting program interpreter: /lib/ld-linux.so.2] Note especially that /lib is now the prefix of our dynamic linker. If you did not receive the output as shown above, or received no output at all, then something is seriously wrong. You will need to investigate and retrace your steps to find out where the problem is and correct it. There is no point in continuing until this is done. Most likely something went wrong with the specs file amendment above. Once you are satisfied that all is well, clean up the test files: rm dummy.c a.out |
|