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 a similar 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.
First, backup the /tools
linker, and
replace it with the adjusted linker we made in chapter 5. We'll also
create a link to its counterpart in /tools/$(gcc -dumpmachine)/bin
:
mv -v /tools/bin/{ld,ld-old} mv -v /tools/$(gcc -dumpmachine)/bin/{ld,ld-old} mv -v /tools/bin/{ld-new,ld} ln -sv /tools/bin/ld /tools/$(gcc -dumpmachine)/bin/ld
Next, amend the GCC specs file so that it points to the new dynamic linker, and so that GCC knows where to find the correct headers and Glibc start files. A sed command accomplishes this:
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 following
commands. Refer to Section 5.2,
“Toolchain Technical Notes,” if necessary.
gcc -dumpspecs | sed \ -e 's@/tools/lib/ld-linux.so.2@/lib/ld-linux.so.2@g' \ -e '/\*startfile_prefix_spec:/{n;s@.*@/usr/lib/ @}' \ -e '/\*cpp:/{n;s@$@ -isystem /usr/include@}' > \ `dirname $(gcc --print-libgcc-file-name)`/specs
It is a good idea to visually inspect the specs file to verify the intended change was actually made.
It is imperative at this point to ensure that the basic functions (compiling and linking) of the adjusted toolchain are working as expected. To do this, perform the following sanity checks:
echo 'main(){}' > dummy.c cc dummy.c -v -Wl,--verbose &> dummy.log 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.
Now make sure that we're setup to use the correct startfiles:
grep -o '/usr/lib.*/crt[1in].*succeeded' dummy.log
If everything is working correctly, there should be no errors, and the output of the last command will be:
/usr/lib/crt1.o succeeded
/usr/lib/crti.o succeeded
/usr/lib/crtn.o succeeded
Verify that the compiler is searching for the correct header files:
grep -B1 '^ /usr/include' dummy.log
This command should return successfully with the following output:
#include <...> search starts here:
/usr/include
Next, verify that the new linker is being used with the correct search paths:
grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'
If everything is working correctly, there should be no errors, and the output of the last command will be:
SEARCH_DIR("/tools/i686-pc-linux-gnu/lib")
SEARCH_DIR("/usr/lib")
SEARCH_DIR("/lib");
Next make sure that we're using the correct libc:
grep "/lib/libc.so.6 " dummy.log
If everything is working correctly, there should be no errors, and the output of the last command will be:
attempt to open /lib/libc.so.6 succeeded
Lastly, make sure GCC is using the correct dynamic linker:
grep found dummy.log
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):
found ld-linux.so.2 at /lib/ld-linux.so.2
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 adjustment. 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 dummy.log