%general-entities; ]> Adjusting the toolchain Now that the temporary C libraries have been installed, all the 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 adjsted. Some people would say that there is black magic juju below this line, but it is really very simple. First the adjusted linker is installed (adjusted at the end of the first pass of Binutils), 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 you missed the earlier warning to retain the Binutils source and build directories from the first pass, dont worry - all is not lost. Just ignore the above command. This results in a small chance of the subsequent testing programs linking against libraries on the host. This is not ideal, but it's not a major problem. The situation is corrected when the second pass of Binutils is installed later on. Now that the adjusted linker is installed, the Binutils build and source direcotries should be removed. The next task is to amend our 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 -e '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 cut-and-pasted in order to ensure correctness - Alternatively the specs file can be edited by hand. This is done simply 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 mande. If you are working on a platform where the name of the dynamic linker is something other than ld-linux.so.2, you must replace ld-linux.so.2 with the name of your platform's dynamic linker in the above commands. Refer back to if necessary. Lastly, 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 of GCC's fixincludes process which runs as part of the GCC build. We'll explain more about this further on in this chapter. Run the following commands to eliminate this possibility: rm -f /tools/lib/gcc/*/*/include/{pthread.h,bits/sigthread.h} It is imperative at this point to stop and ensure that the basic functions (compiling and linking) of the new toolchain are working as expected. To perform a simple 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 especially that /tools/lib appears as the prefix of our dynamic linker. If the output is not as shown above, or there was 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. 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. Second, ensure your PATH is correct. You can check this by running echo $PATH and verifying that /tools/bin is at the head of the list. If the PATH is wrong it could mean you're not logged in as user lfs or something went wrong back in . Third, something may have gone wrong with the specs file amendment above. In this case redo the specs file amendment being careful to cut-and-paste the commands. Once you are satisfied that all is well, clean up the test files: rm dummy.c a.out