blob: 522727785715e9740753bcd398b2f016434a4834 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
|
<sect1 id="ch06-adjustingtoolchain">
<title>Re-adjusting the toolchain</title>
<?dbhtml filename="adjustingtoolchain.html" dir="chapter06"?>
<para>Now that the new C libraries have been installed, it's time to re-adjust
our toolchain. We'll adjust it so that it will link any newly compiled program
against the new C libraries. Basically, this is the reverse of what we did
in the "Locking in" stage in the beginning of the previous chapter.</para>
<para>The first thing to do is to adjust the linker scripts. For this we
retained the source and build directories from the second pass over Binutils.
Install the adjusted linker scripts by running the following from within the
<filename class="directory">binutils-build</filename> directory:</para>
<para><screen><userinput>make -C ld install-data-local</userinput></screen></para>
<para>The linker scripts now contain
no mention of <filename class="directory">/tools/lib</filename> anymore.
From now on every compiled program will link <emphasis>only</emphasis>
against the libraries in <filename>/usr/lib</filename> and
<filename>/lib</filename>.</para>
<para>You can now remove the Binutils source and build directories.</para>
<para>The next thing to do is to amend our GCC specs file so that it points
to the new dynamic linker. Just like earlier on, we use a sed to accomplish
this:</para>
<para><screen><userinput>SPECFILE=/tools/lib/gcc-lib/*/*/specs
sed -e 's@/tools/lib/ld.so.1@/lib/ld.so.1@g' \
-e 's@/tools/lib/ld-linux.so.2@/lib/ld-linux.so.2@g' \
$SPECFILE > newspecfile
mv newspecfile $SPECFILE
unset SPECFILE</userinput></screen></para>
<para>Again, cutting and pasting the above is recommended. And just like
before, it is a good idea to check the linker scripts and the specs file to
ensure the intended changes were actually made.</para>
<para>Note that the linker scripts will still contain a reference to
<filename class="directory">/tools/i686-pc-linux-gnu/lib</filename>. This
is unavoidable, but luckily does not present a problem. There are no
libraries in that location as all the temporary tools libraries are
located in <filename class="directory">/tools/lib</filename>.</para>
<caution><para>It is imperative at this point to stop and ensure that the
basic functionality of the adjusted toolchain is working as expected. 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 ': /lib'</userinput></screen></para>
<para>If everything is working correctly, the output of the last command will
be:</para>
<para><screen>[Requesting program interpreter: /lib/ld-linux.so.2]
</screen></para>
<para>If you did not receive the output as shown above then something is
seriously wrong. 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>/lib</filename> now 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>
</sect1>
|
