5.9. Adjusting the Toolchain
Now that the temporary C libraries have been installed, all tools compiled in the rest of this chapter should be linked against these libraries. In order to accomplish this, the linker and the compiler's specs file need to be adjusted.
The linker, adjusted at the end of the first pass of Binutils, is installed by running the following command from within the binutils-build directory:
make -C ld install
From this point onwards, everything will link only against the libraries in /tools/lib.
![[Note]](../images/note.png)
Note
If the earlier warning to retain the Binutils source and build directories from the first pass was missed, ignore the above command. This results in a small chance that the subsequent testing programs will link against libraries on the host. This is not ideal, but it is not a major problem. The situation is corrected when the second pass of Binutils is installed later.
Now that the adjusted linker is installed, the Binutils build and source directories should be removed.
The next task is to amend the GCC specs file so that it points to the new dynamic linker. A simple sed script will accomplish this:
SPECFILE=`gcc --print-file specs` &&
sed 's@ /lib/ld-linux.so.2@ /tools/lib/ld-linux.so.2@g' \
$SPECFILE > tempspecfile &&
mv -f tempspecfile $SPECFILE &&
unset SPECFILE
It is recommended that the above command be copy-and-pasted in order to ensure accuracy. Alternatively, the specs file can be edited by hand. This is done by replacing every occurrence of “/lib/ld-linux.so.2” with “/tools/lib/ld-linux.so.2”
Be sure to visually inspect the specs file in order to verify the intended changes have been made.
![[Important]](../images/important.png)
Important
If working on a platform where the name of the dynamic linker is something other than ld-linux.so.2, replace “ld-linux.so.2” with the name of the platform's dynamic linker in the above commands. Refer back to Section 5.3, “Toolchain Technical Notes,” if necessary.
There is a possibility that some include files from the host system have found their way into GCC's private include dir. This can happen as a result of GCC's “fixincludes” process, which runs as part of the GCC build. This is explained in more detail later in this chapter. Run the following command to eliminate this possibility:
rm -f /tools/lib/gcc/*/*/include/{pthread.h,bits/sigthread.h}
![[Caution]](../images/caution.png)
Caution
At this point, it is imperative to stop and ensure that the basic functions (compiling and linking) of the new toolchain are working as expected. To perform a sanity check, run the following commands:
echo 'main(){}' > dummy.c
cc dummy.c
readelf -l a.out | grep ': /tools'
If everything is working correctly, there should be no errors, and the output of the last command will be of the form:
[Requesting program interpreter:
/tools/lib/ld-linux.so.2]
Note that /tools/lib appears as the prefix of the dynamic linker.
If the output is not shown as above or there was no output at all, then something is wrong. Investigate and retrace the steps to find out where the problem is and correct it. This issue must be resolved before continuing on. First, perform the sanity check again, using gcc instead of cc. If this works, then the /tools/bin/cc symlink is missing. Revisit Section 5.5, “GCC-3.4.1 - Pass 1,” and install the symlink. Next, ensure that the PATH is correct. This can be checked by running echo $PATH and verifying that /tools/bin is at the head of the list. If the PATH is wrong it could mean that you are not logged in as user lfs or that something went wrong back in Section 4.4, “Setting Up the Environment.” Another option is that something may have gone wrong with the specs file amendment above. In this case, redo the specs file amendment, being careful to copy-and-paste the commands.
Once all is well, clean up the test files:
rm dummy.c a.out