source: chapter05/lockingglibc.xml@ 76b9eb4

<sect1 id="ch05-locking-glibc">
<title>"Locking in" Glibc</title>
<?dbhtml filename="lockingglibc.html" dir="chapter05"?>

<para>Now that the temporary C libraries have been installed, we want all
the tools compiled in the rest of this chapter to be linked against these
libraries. To accomplish this, we need to adjust the linker and the compiler's
specs file.</para>

<para>First install the adjusted linker by running the following from within
the <filename class="directory">binutils-build</filename> directory:</para>

<para><screen><userinput>make -C ld install</userinput></screen></para>

<para>The linker was adjusted a little while back, at the end of the first
pass of Binutils. From this point onwards everything will link <emphasis>only
</emphasis> against the libraries in <filename>/tools/lib</filename>.</para>

<para>Now that the adjusted linker is installed, you have to remove the
Binutils build and source directories.</para>

<para>The next thing to do is to amend our GCC specs file so that it points
to the new dynamic linker. A simple sed will accomplish this:</para>
   
<para><screen><userinput>SPECFILE=/tools/lib/gcc-lib/*/*/specs
sed -e 's@/lib/ld-linux.so.2@/tools/lib/ld-linux.so.2@g' \
&nbsp;&nbsp;&nbsp;&nbsp;$SPECFILE > tempspecfile
mv tempspecfile $SPECFILE
unset SPECFILE</userinput></screen></para>

<para>We recommend that you cut-and-paste the above rather than try and type it
all in. Or you can edit the specs file by hand if you want to: just replace any
occurrence of "/lib/ld-linux.so.2" with "/tools/lib/ld-linux.so.2".</para>

<important><para>If you are working on a platform where the name of the dynamic
linker is something other than <filename>ld-linux.so.2</filename>, you
<emphasis>must</emphasis> substitute <filename>ld-linux.so.2</filename> with the
name of your platform's dynamic linker in the above commands. Refer back to
<xref linkend="ch05-toolchaintechnotes"/> if necessary.</para></important>

<para>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
because of GCC's "fixincludes" process which runs as part of the GCC build.
We'll explain more about this further on in this chapter.  For now, run the
following commands to eliminate this possibility:</para>

<para><screen><userinput>rm -f /tools/lib/gcc-lib/*/*/include/{pthread.h,bits/sigthread.h}</userinput></screen></para>

<caution><para>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.
For this we are going to perform a simple sanity check:</para>

<para><screen><userinput>echo 'main(){}' > dummy.c
gcc dummy.c
readelf -l a.out | grep ': /tools'</userinput></screen></para>

<para>If everything is working correctly, there should be no errors, and the
output of the last command will be:</para>

<blockquote><screen>[Requesting program interpreter: /tools/lib/ld-linux.so.2]</screen></blockquote>

<para>If you did not receive the output as shown above, then something is
seriously wrong. This includes if the output of the command is blank!
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. Most likely something went wrong with the specs file
amendment above. Note especially that <filename>/tools/lib</filename> appears
as the prefix of our dynamic linker. Of course, if you are working on a
platform where the name of the dynamic linker is something other than
<filename>ld-linux.so.2</filename>, then the output will be slightly different.
</para>

<para>Once you are satisfied that all is well, clean up the test files:</para>

<para><screen><userinput>rm dummy.c a.out</userinput></screen></para>
</caution>

<para>This completes the installation of the self-contained toolchain, and it
can now be used to build the rest of the temporary tools.</para>

</sect1>