1 | <sect1 id="ch05-locking-glibc">
|
---|
2 | <title>"Locking in" Glibc</title>
|
---|
3 | <?dbhtml filename="lockingglibc.html" dir="chapter05"?>
|
---|
4 |
|
---|
5 | <para>Now that the temporary C libraries have been installed, we want all
|
---|
6 | the tools compiled in the rest of this chapter to be linked against these
|
---|
7 | libraries. To accomplish this, we need to adjust the linker and the compiler's
|
---|
8 | specs file.</para>
|
---|
9 |
|
---|
10 | <para>First install the adjusted linker by running the following from within
|
---|
11 | the <filename class="directory">binutils-build</filename> directory:</para>
|
---|
12 |
|
---|
13 | <screen><userinput>make -C ld install</userinput></screen>
|
---|
14 |
|
---|
15 | <para>The linker was adjusted a little while back, at the end of the first
|
---|
16 | pass of Binutils. From this point onwards everything will link <emphasis>only
|
---|
17 | </emphasis> against the libraries in <filename>/tools/lib</filename>.</para>
|
---|
18 |
|
---|
19 | <note><para>If you somehow missed the earlier warning to retain the Binutils
|
---|
20 | source and build directories from the first pass or otherwise accidentally
|
---|
21 | deleted them or just don't have access to them, don't worry, all is not lost.
|
---|
22 | Just ignore the above command. The result is a small chance of subsequent
|
---|
23 | programs linking against libraries on the host. This is not ideal, however,
|
---|
24 | it's not a major problem. The situation is corrected when we install the
|
---|
25 | second pass of Binutils later on.</para></note>
|
---|
26 |
|
---|
27 | <para>Now that the adjusted linker is installed, you have to remove the
|
---|
28 | Binutils build and source directories.</para>
|
---|
29 |
|
---|
30 | <para>The next thing to do is to amend our GCC specs file so that it points
|
---|
31 | to the new dynamic linker. A simple sed will accomplish this:</para>
|
---|
32 |
|
---|
33 | <!-- Ampersands are needed to allow cut and paste -->
|
---|
34 |
|
---|
35 | <screen><userinput>SPECFILE=/tools/lib/gcc-lib/*/*/specs &&
|
---|
36 | sed -e 's@/lib/ld-linux.so.2@/tools/lib/ld-linux.so.2@g' \
|
---|
37 | $SPECFILE > tempspecfile &&
|
---|
38 | mv -f tempspecfile $SPECFILE &&
|
---|
39 | unset SPECFILE</userinput></screen>
|
---|
40 |
|
---|
41 | <para>We recommend that you cut-and-paste the above rather than try and type it
|
---|
42 | all in. Or you can edit the specs file by hand if you want to: just replace any
|
---|
43 | occurrence of "/lib/ld-linux.so.2" with "/tools/lib/ld-linux.so.2".</para>
|
---|
44 |
|
---|
45 | <important><para>If you are working on a platform where the name of the dynamic
|
---|
46 | linker is something other than <filename>ld-linux.so.2</filename>, you
|
---|
47 | <emphasis>must</emphasis> substitute <filename>ld-linux.so.2</filename> with the
|
---|
48 | name of your platform's dynamic linker in the above commands. Refer back to
|
---|
49 | <xref linkend="ch05-toolchaintechnotes"/> if necessary.</para></important>
|
---|
50 |
|
---|
51 | <para>Lastly, there is a possibility that some include files from the host
|
---|
52 | system have found their way into GCC's private include dir. This can happen
|
---|
53 | because of GCC's "fixincludes" process which runs as part of the GCC build.
|
---|
54 | We'll explain more about this further on in this chapter. For now, run the
|
---|
55 | following commands to eliminate this possibility:</para>
|
---|
56 |
|
---|
57 | <screen><userinput>rm -f /tools/lib/gcc-lib/*/*/include/{pthread.h,bits/sigthread.h}</userinput></screen>
|
---|
58 |
|
---|
59 | <!-- HACK - Force some whitespace to appease tidy -->
|
---|
60 | <literallayout></literallayout>
|
---|
61 |
|
---|
62 | <caution><para>It is imperative at this point to stop and ensure that the basic
|
---|
63 | functions (compiling and linking) of the new toolchain are working as expected.
|
---|
64 | For this we are going to perform a simple sanity check:</para>
|
---|
65 |
|
---|
66 | <screen><userinput>echo 'main(){}' > dummy.c
|
---|
67 | gcc dummy.c
|
---|
68 | readelf -l a.out | grep ': /tools'</userinput></screen>
|
---|
69 |
|
---|
70 | <para>If everything is working correctly, there should be no errors, and the
|
---|
71 | output of the last command will be:</para>
|
---|
72 |
|
---|
73 | <blockquote><screen>[Requesting program interpreter: /tools/lib/ld-linux.so.2]</screen></blockquote>
|
---|
74 |
|
---|
75 | <para>If you did not receive the output as shown above, or received no output at
|
---|
76 | all, then something is seriously wrong. You will need to investigate and retrace
|
---|
77 | your steps to find out where the problem is and correct it. There is no point in
|
---|
78 | continuing until this is done. Most likely something went wrong with the specs
|
---|
79 | file amendment above. Note especially that <filename>/tools/lib</filename>
|
---|
80 | appears as the prefix of our dynamic linker. Of course, if you are working on a
|
---|
81 | platform where the name of the dynamic linker is something other than
|
---|
82 | <filename>ld-linux.so.2</filename>, then the output will be slightly
|
---|
83 | different.</para>
|
---|
84 |
|
---|
85 | <para>Once you are satisfied that all is well, clean up the test files:</para>
|
---|
86 |
|
---|
87 | <screen><userinput>rm dummy.c a.out</userinput></screen>
|
---|
88 | </caution>
|
---|
89 |
|
---|
90 | <!-- HACK - Force some whitespace to appease tidy -->
|
---|
91 | <literallayout></literallayout>
|
---|
92 |
|
---|
93 | <para>This completes the installation of the self-contained toolchain, and it
|
---|
94 | can now be used to build the rest of the temporary tools.</para>
|
---|
95 |
|
---|
96 | </sect1>
|
---|
97 |
|
---|