1 | <sect1 id="ch06-adjustingtoolchain">
|
---|
2 | <title>Re-adjusting the toolchain</title>
|
---|
3 | <?dbhtml filename="adjustingtoolchain.html" dir="chapter06"?>
|
---|
4 |
|
---|
5 | <para>Now that the new C libraries have been installed, it's time to re-adjust
|
---|
6 | our toolchain. We'll adjust it so that it will link any newly compiled program
|
---|
7 | against the new C libraries. Basically, this is the reverse of what we did
|
---|
8 | in the "locking in" stage in the beginning of the previous chapter.</para>
|
---|
9 |
|
---|
10 | <para>The first thing to do is to adjust the linker. For this we retained the
|
---|
11 | source and build directories from the second pass over Binutils. Install the
|
---|
12 | adjusted linker by running the following from within the
|
---|
13 | <filename class="directory">binutils-build</filename> directory:</para>
|
---|
14 |
|
---|
15 | <screen><userinput>make -C ld INSTALL=/tools/bin/install install</userinput></screen>
|
---|
16 |
|
---|
17 | <note><para>If you somehow missed the earlier warning to retain the Binutils
|
---|
18 | source and build directories from the second pass in Chapter 5 or otherwise
|
---|
19 | accidentally deleted them or just don't have access to them, don't worry, all is
|
---|
20 | not lost. Just ignore the above command. The result will be that the next
|
---|
21 | package, Binutils, will link against the Glibc libraries in
|
---|
22 | <filename class="directory">/tools</filename> rather than
|
---|
23 | <filename class="directory">/usr</filename>. This is not ideal, however, our
|
---|
24 | testing has shown that the resulting Binutils program binaries should be
|
---|
25 | identical.</para></note>
|
---|
26 |
|
---|
27 | <para>From now on every compiled program will link <emphasis>only</emphasis>
|
---|
28 | against the libraries in <filename>/usr/lib</filename> and
|
---|
29 | <filename>/lib</filename>. The extra
|
---|
30 | <userinput>INSTALL=/tools/bin/install</userinput> is needed because the Makefile
|
---|
31 | created during the second pass still contains the reference to
|
---|
32 | <filename>/usr/bin/install</filename>, which we obviously haven't installed yet.
|
---|
33 | Some host distributions contain a <filename class="symlink">ginstall</filename>
|
---|
34 | symbolic link which takes precedence in the Makefile and thus can cause a
|
---|
35 | problem here. The above command takes care of this also.</para>
|
---|
36 |
|
---|
37 | <para>You can now remove the Binutils source and build directories.</para>
|
---|
38 |
|
---|
39 | <para>The next thing to do is to amend our GCC specs file so that it points
|
---|
40 | to the new dynamic linker. Just like earlier on, we use a sed to accomplish
|
---|
41 | this:</para>
|
---|
42 |
|
---|
43 | <!-- Ampersands are needed to allow cut and paste -->
|
---|
44 |
|
---|
45 | <screen><userinput>SPECFILE=/tools/lib/gcc-lib/*/*/specs &&
|
---|
46 | sed -e 's@ /tools/lib/ld-linux.so.2@ /lib/ld-linux.so.2@g' \
|
---|
47 | $SPECFILE > newspecfile &&
|
---|
48 | mv -f newspecfile $SPECFILE &&
|
---|
49 | unset SPECFILE</userinput></screen>
|
---|
50 |
|
---|
51 | <para>Again, cutting and pasting the above is recommended. And just like
|
---|
52 | before, it is a good idea to check the specs file to ensure the intended
|
---|
53 | changes were actually made.</para>
|
---|
54 |
|
---|
55 | <important><para>If you are working on a platform where the name of the dynamic
|
---|
56 | linker is something other than <filename>ld-linux.so.2</filename>, you
|
---|
57 | <emphasis>must</emphasis> substitute <filename>ld-linux.so.2</filename> with the
|
---|
58 | name of your platform's dynamic linker in the above commands. Refer back to
|
---|
59 | <xref linkend="ch05-toolchaintechnotes"/> if necessary.</para></important>
|
---|
60 |
|
---|
61 | <!-- HACK - Force some whitespace to appease tidy -->
|
---|
62 | <literallayout></literallayout>
|
---|
63 |
|
---|
64 | <caution><para>It is imperative at this point to stop and ensure that the
|
---|
65 | basic functions (compiling and linking) of the adjusted toolchain are working
|
---|
66 | as expected. For this we are going to perform a simple sanity check:</para>
|
---|
67 |
|
---|
68 | <screen><userinput>echo 'main(){}' > dummy.c
|
---|
69 | gcc dummy.c
|
---|
70 | readelf -l a.out | grep ': /lib'</userinput></screen>
|
---|
71 |
|
---|
72 | <para>If everything is working correctly, there should be no errors, and the
|
---|
73 | output of the last command will be:</para>
|
---|
74 |
|
---|
75 | <blockquote><screen>[Requesting program interpreter: /lib/ld-linux.so.2]</screen></blockquote>
|
---|
76 |
|
---|
77 | <para>If you did not receive the output as shown above, or received no output at
|
---|
78 | all, then something is seriously wrong. You will need to investigate and retrace
|
---|
79 | your steps to find out where the problem is and correct it. There is no point in
|
---|
80 | continuing until this is done. Most likely something went wrong with the specs
|
---|
81 | file amendment above. Note especially that <filename>/lib</filename> now appears
|
---|
82 | as the prefix of our dynamic linker. Of course, if you are working on a platform
|
---|
83 | where the name of the dynamic linker is something other than
|
---|
84 | <filename>ld-linux.so.2</filename>, then the output will be slightly
|
---|
85 | different.</para>
|
---|
86 |
|
---|
87 | <para>Once you are satisfied that all is well, clean up the test files:</para>
|
---|
88 |
|
---|
89 | <screen><userinput>rm dummy.c a.out</userinput></screen>
|
---|
90 | </caution>
|
---|
91 |
|
---|
92 | <!-- HACK - Force some whitespace to appease tidy -->
|
---|
93 | <literallayout></literallayout>
|
---|
94 |
|
---|
95 | </sect1>
|
---|
96 |
|
---|