6.12. Re-adjusting the Toolchain

Now that the final C libraries have been installed, it is time to adjust the toolchain again. The toolchain will be adjusted so that it will link any newly compiled program against these new libraries. This is the same process used in the “Adjusting” phase in the beginning of Chapter 5, but with the adjustments reversed. In Chapter 5, the chain was guided from the host's /{,usr/}lib directories to the new /tools/lib directory. Now, the chain will be guided from that same /tools/lib directory to the LFS /{,usr/}lib directories.

Start by adjusting the linker. The source and build directories from the second pass of Binutils were retained for this purpose. Install the adjusted linker by running the following command from within the binutils-build directory:

make -C ld INSTALL=/tools/bin/install install

Note

If the earlier warning to retain the Binutils source and build directories from the second pass in Chapter 5 was missed, or if they were accidentally deleted or are inaccessible, 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, 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 option is needed because the Makefile file created during the second pass still contains the reference to /usr/bin/install, which has not been installed yet. Some host distributions contain a ginstall symbolic link which takes precedence in the Makefile file and can cause a problem. The above command takes care of this issue.

Remove the Binutils source and build directories now.

Next, amend the GCC specs file so that it points to the new dynamic linker. A perl command accomplishes this:

perl -pi -e 's@ /tools/lib/ld-linux.so.2@ /lib/ld-linux.so.2@g;' \
    -e 's@\*startfile_prefix_spec:\n@$_/usr/lib/ @g;' \
        `gcc --print-file specs`

It is a good idea to visually inspect the specs file to verify the intended change was actually made.

Important

If working on a platform where the name of the dynamic linker is something other than ld-linux.so.2, substitute “ld-linux.so.2” with the name of the platform's dynamic linker in the above commands. Refer back to Section 5.2, “Toolchain Technical Notes,” if necessary.

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. To do this, perform a 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 that /lib is now the prefix of our dynamic linker.

If the output does not appear as shown above or is not received at all, then something is seriously wrong. Investigate and retrace the steps to find out where the problem is and correct it. The most likely reason is that something went wrong with the specs file amendment above. Any issues will need to be resolved before continuing on with the process.

Once everything is working correctly, clean up the test files:

rm -v dummy.c a.out