10.9. Adjusting the Toolchain
Now we adjust GCC's specs so that they point to the new dynamic linker. A perl command accomplishes this:
gcc -dumpspecs | \
perl -p -e 's@/tools/lib/ld@/lib/ld@g;' \
-e 's@/tools/lib64/ld@/lib64/ld@g;' \
-e 's@\*startfile_prefix_spec:\n@$_/usr/lib/ @g;' > \
$(dirname $(gcc --print-libgcc-file-name))/specs
The perl command above
makes 2 modifications to GCC's specs: it removes “/tools” from the pathname to the dynamic linker,
and adds “/usr/lib/” to the
startfile_prefix_spec. It is a good idea to visually inspect the
specs file, and compare with the output
of gcc -dumpspecs, to
verify that the intended changes were actually made.
![[Caution]](../images/caution.png)
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:
For 32 bit ABI:
echo 'int main(){}' > dummy.c
gcc ${BUILD32} 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:
[Requesting program interpreter: /lib/ld.so.1]For 64 bit ABI:
echo 'main(){}' > dummy.c
gcc ${BUILD64} 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:
[Requesting program interpreter: /lib64/ld64.so.1]
Note that /lib or /lib64 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