1 | <?xml version="1.0" encoding="ISO-8859-1"?>
|
---|
2 | <!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
|
---|
3 | <!ENTITY % general-entities SYSTEM "../general.ent">
|
---|
4 | %general-entities;
|
---|
5 | ]>
|
---|
6 | <sect1 id="ch-system-readjusting">
|
---|
7 | <title>Re-adjusting the Toolchain</title>
|
---|
8 | <?dbhtml filename="readjusting.html"?>
|
---|
9 |
|
---|
10 | <para>Now that the final C libraries have been installed, it is time to adjust
|
---|
11 | the toolchain again. The toolchain will be adjusted so that it will link any
|
---|
12 | newly compiled program against these new libraries. This is the same process
|
---|
13 | used in the <quote>Adjusting</quote> phase in the beginning of <xref
|
---|
14 | linkend="chapter-temporary-tools"/>, but with the adjustments reversed. In <xref
|
---|
15 | linkend="chapter-temporary-tools"/>, the chain was guided from the host's
|
---|
16 | <filename class="directory">/{,usr/}lib</filename> directories to the new
|
---|
17 | <filename class="directory">/tools/lib</filename> directory. Now, the chain will
|
---|
18 | be guided from that same <filename class="directory">/tools/lib</filename>
|
---|
19 | directory to the LFS <filename class="directory">/{,usr/}lib</filename>
|
---|
20 | directories.</para>
|
---|
21 |
|
---|
22 | <para>Start by adjusting the linker. The source and build directories from the
|
---|
23 | second pass of Binutils were retained for this purpose. Install the adjusted
|
---|
24 | linker by running the following command from within the <filename
|
---|
25 | class="directory">binutils-build</filename> directory:</para>
|
---|
26 |
|
---|
27 | <screen><userinput>make -C ld INSTALL=/tools/bin/install install</userinput></screen>
|
---|
28 |
|
---|
29 | <note><para>If the earlier warning to retain the Binutils source and
|
---|
30 | build directories from the second pass in <xref
|
---|
31 | linkend="chapter-temporary-tools"/> was missed, or if they were
|
---|
32 | accidentally deleted or are inaccessible, ignore the above command.
|
---|
33 | The result will be that the next package, Binutils, will link against
|
---|
34 | the C libraries in <filename class="directory">/tools</filename>
|
---|
35 | rather than in <filename class="directory">/{,usr/}lib</filename>.
|
---|
36 | This is not ideal, however, testing has shown that the resulting
|
---|
37 | Binutils program binaries should be identical.</para></note>
|
---|
38 |
|
---|
39 | <para>From now on, every compiled program will link only against the
|
---|
40 | libraries in <filename class="directory">/usr/lib</filename> and
|
---|
41 | <filename class="directory">/lib</filename>. The extra
|
---|
42 | <parameter>INSTALL=/tools/bin/install</parameter> option is needed
|
---|
43 | because the <filename>Makefile</filename> file created during the
|
---|
44 | second pass still contains the reference to
|
---|
45 | <command>/usr/bin/install</command>, which has not been installed yet.
|
---|
46 | Some host distributions contain a <filename
|
---|
47 | class="symlink">ginstall</filename> symbolic link which takes
|
---|
48 | precedence in the <filename>Makefile</filename> file and can cause a
|
---|
49 | problem. The above command takes care of this issue.</para>
|
---|
50 |
|
---|
51 | <para>Remove the Binutils source and build directories now.</para>
|
---|
52 |
|
---|
53 | <para>Next, amend the GCC specs file so that it points to the new
|
---|
54 | dynamic linker. A <command>perl</command> command accomplishes this:</para>
|
---|
55 |
|
---|
56 | <screen><userinput>perl -pi -e 's@ /tools/lib/ld-linux.so.2@ /lib/ld-linux.so.2@g;' \
|
---|
57 | -e 's@\*startfile_prefix_spec:\n@$_/usr/lib/ @g;' \
|
---|
58 | `gcc --print-file specs`</userinput></screen>
|
---|
59 |
|
---|
60 | <para>It is a good idea to visually inspect the specs file to verify the intended
|
---|
61 | change was actually made.</para>
|
---|
62 |
|
---|
63 | <important><para>If working on a platform where the name of the
|
---|
64 | dynamic linker is something other than
|
---|
65 | <filename class="libraryfile">ld-linux.so.2</filename>, substitute
|
---|
66 | <quote>ld-linux.so.2</quote> with the name of the platform's
|
---|
67 | dynamic linker in the above commands. Refer back to <xref
|
---|
68 | linkend="ch-tools-toolchaintechnotes" role=","/> if
|
---|
69 | necessary.</para></important>
|
---|
70 |
|
---|
71 | <beginpage/>
|
---|
72 |
|
---|
73 | <caution><para>It is imperative at this point to stop and ensure that
|
---|
74 | the basic functions (compiling and linking) of the adjusted toolchain
|
---|
75 | are working as expected. To do this, perform a sanity
|
---|
76 | check:</para>
|
---|
77 |
|
---|
78 | <screen><userinput>echo 'main(){}' > dummy.c
|
---|
79 | cc dummy.c
|
---|
80 | readelf -l a.out | grep ': /lib'</userinput></screen>
|
---|
81 |
|
---|
82 | <para>If everything is working correctly, there should be no errors,
|
---|
83 | and the output of the last command will be (allowing for
|
---|
84 | platform-specific differences in dynamic linker name):</para>
|
---|
85 |
|
---|
86 | <screen><computeroutput>[Requesting program interpreter: /lib/ld-linux.so.2]</computeroutput></screen>
|
---|
87 |
|
---|
88 | <para>Note that <filename class="directory">/lib</filename> is now
|
---|
89 | the prefix of our dynamic linker.</para>
|
---|
90 |
|
---|
91 | <para>If the output does not appear as shown above or is not received
|
---|
92 | at all, then something is seriously wrong. Investigate and retrace the
|
---|
93 | steps to find out where the problem is and correct it. The most likely
|
---|
94 | reason is that something went wrong with the specs file amendment
|
---|
95 | above. Any issues will need to be resolved before continuing on with
|
---|
96 | the process.</para>
|
---|
97 |
|
---|
98 | <para>Once everything is working correctly, clean up the test
|
---|
99 | files:</para>
|
---|
100 |
|
---|
101 | <screen><userinput>rm dummy.c a.out</userinput></screen></caution>
|
---|
102 |
|
---|
103 | </sect1>
|
---|
104 |
|
---|