LAP - Actual Build - Part 3, Reconfigure

Now we have our final, functional Glibc, it is time to let the system know about it.  We do this by effectively reversing some of the changes we made when we first configured the Toolchain.

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

Remember when we were building binutils for the Toolchain, and we made special ld-new file which did not know about the /tools install?  Well now is the time to use it.  We back up the /tools aware versions, and replace them with ld-new either directly or by symbolic link.  I know what is going on here, but I am still no wiser as to what the 'ld' program actually does.

I have a feeling that Specs is hovering on the horizon of .. oh yes, there it is.

gcc -dumpspecs | sed -e 's@/tools@@g' -e '/\*startfile_prefix_spec:/{n;s@.*@/usr/lib/ @}' -e '/\*cpp:/{n;s@$@ -isystem /usr/include@}' > `dirname $(gcc --print-libgcc-file-name)`/specs

I am … not even … but surely … nothing human? … … Let's just say that this undoes whatever it was we did to the specs file the last time.  From the book:-

“It is a good idea to visually inspect the specs file to verify the intended change was actually made.”

You know what?  Fuck off.  I value my eyesight more than that.

Lets run the compiler test that we are familiar with by now:

echo 'main(){}' > dummy.c
cc dummy.c -v -Wl,--verbose &> dummy.log
readelf -l a.out | grep ': /lib'

We are not running the long filename-gcc program any more, it is just [cc] now.  Also it has a couple of other new options, which I do not intend to dwell on.  The output was:

      [Requesting program interpreter: /lib/ld-linux.so.2]

Which is exactly what I should have got.  What you are really looking for here is the interpreter being found in /lib rather than /tools/lib, because this means we are moving away from the Toolchain, bit by bit.  We are going to check for some more this time though:

grep -o '/usr/lib.*/crt[1in].*succeeded' dummy.log

So here we are searching for 'startfiles' according to the book.  Hmmm.  Output was:

/usr/lib/crt1.o succeeded 
/usr/lib/crti.o succeeded 
/usr/lib/crtn.o succeeded

Which is … good!

We also need to check that it gets the right header files.  We spent enough time uncompressing the Kernel archive, so it bloody well better have.

grep -B1 '^ /usr/include' dummy.log

The output showed:

#include <...> search starts here: 
 /usr/include

Which is just fine.  Next we want to verify that the correct search paths are being used:

grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'

SEARCH_DIR("/tools/i686-pc-linux-gnu/lib") 
SEARCH_DIR("/usr/lib") 
SEARCH_DIR("/lib");

Cha-ching once more.  The penultimate test is to make sure the correct libc is being used:

grep "/lib.*/libc.so.6 " dummy.log

attempt to open /lib/libc.so.6 succeeded

Once again, I was spot on.  Finally I apparently need to make sure that GCC is using the correct dynamic linker (which sounds like a hyperactive speed dater):

grep found dummy.log

found ld-linux.so.2 at /lib/ld-linux.so.2 

One final time, I am satisfied with the test results.  One quick clean up and we can move on:

rm -v dummy.c a.out dummy.log