%general-entities; ]> 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. 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 point GCC to the new dynamic linker. This is done by dumping GCC's specs file to a location where GCC will look for it by default. A simple sed substitution then alters the dynamic linker that GCC will use: SPECFILE=`dirname $(gcc -print-libgcc-file-name)`/specs && gcc -dumpspecs > $SPECFILE && sed 's@^/lib/ld-linux.so.2@/tools&@g' $SPECFILE > tempspecfile && mv -vf 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. 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 if necessary. There is a possibility that some header 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 commands to remove those header files (you may find it easier to copy and paste these commands, rather than typing them by hand, due to their length): GCC_INCLUDEDIR=`dirname $(gcc -print-libgcc-file-name)`/include && find ${GCC_INCLUDEDIR}/* -maxdepth 0 -xtype d -exec rm -rf '{}' \; && rm -vf `grep -l "DO NOT EDIT THIS FILE" ${GCC_INCLUDEDIR}/*` && unset GCC_INCLUDEDIR 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 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 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 -v dummy.c a.out