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-tools-adjusting">
|
---|
7 | <title>Adjusting the Toolchain</title>
|
---|
8 | <?dbhtml filename="adjusting.html"?>
|
---|
9 |
|
---|
10 | <para>Now that the temporary C libraries have been installed, all
|
---|
11 | tools compiled in the rest of this chapter should be linked against
|
---|
12 | these libraries. In order to accomplish this, the linker and the
|
---|
13 | compiler's specs file need to be adjusted.</para>
|
---|
14 |
|
---|
15 | <para>The linker, adjusted at the end of the first pass of Binutils,
|
---|
16 | is installed by running the following command from within the
|
---|
17 | <filename class="directory">binutils-build</filename> directory:</para>
|
---|
18 |
|
---|
19 | <screen><userinput>make -C ld install</userinput></screen>
|
---|
20 |
|
---|
21 | <para>From this point onwards, everything will link only
|
---|
22 | against the libraries in <filename class="directory">/tools/lib</filename>.</para>
|
---|
23 |
|
---|
24 | <note><para>If the earlier warning to retain the Binutils source and
|
---|
25 | build directories from the first pass was missed, ignore the above
|
---|
26 | command. This results in a small chance that the subsequent testing
|
---|
27 | programs will link against libraries on the host. This is not ideal,
|
---|
28 | but it is not a major problem. The situation is corrected when the
|
---|
29 | second pass of Binutils is installed later.</para></note>
|
---|
30 |
|
---|
31 | <para>Now that the adjusted linker is installed, the Binutils build and source
|
---|
32 | directories should be removed.</para>
|
---|
33 |
|
---|
34 | <para>The next task is to point GCC to the new dynamic linker. This is done by
|
---|
35 | dumping GCC's <quote>specs</quote> file to a location where GCC will look for it
|
---|
36 | by default. A simple <command>sed</command> substitution then alters the
|
---|
37 | dynamic linker that GCC will use:</para>
|
---|
38 |
|
---|
39 | <!-- Ampersands are needed to allow copy and paste -->
|
---|
40 |
|
---|
41 | <screen><userinput>SPECFILE=`dirname $(gcc -print-libgcc-file-name)`/specs &&
|
---|
42 | gcc -dumpspecs > $SPECFILE &&
|
---|
43 | sed 's@^/lib/ld-linux.so.2@/tools&@g' $SPECFILE > tempspecfile &&
|
---|
44 | mv -vf tempspecfile $SPECFILE &&
|
---|
45 | unset SPECFILE</userinput></screen>
|
---|
46 |
|
---|
47 | <para>It is recommended that the above
|
---|
48 | command be copy-and-pasted in order to ensure accuracy.
|
---|
49 | Alternatively, the specs file can be edited by hand. This is done by
|
---|
50 | replacing every occurrence of <quote>/lib/ld-linux.so.2</quote> with
|
---|
51 | <quote>/tools/lib/ld-linux.so.2</quote></para>
|
---|
52 |
|
---|
53 | <para>Be sure to visually inspect the specs file in order to verify the
|
---|
54 | intended changes have been made.</para>
|
---|
55 |
|
---|
56 | <important><para>If working on a platform where the name of the
|
---|
57 | dynamic linker is something other than
|
---|
58 | <filename class="libraryfile">ld-linux.so.2</filename>, replace
|
---|
59 | <quote>ld-linux.so.2</quote> with the name of the platform's
|
---|
60 | dynamic linker in the above commands. Refer back to <xref
|
---|
61 | linkend="ch-tools-toolchaintechnotes" role=","/> if
|
---|
62 | necessary.</para></important>
|
---|
63 |
|
---|
64 | <para>During the build process, GCC runs a script
|
---|
65 | (<command>fixincludes</command>) that scans the system for header files that may
|
---|
66 | need to be fixed (they might contain syntax errors, for example), and installs
|
---|
67 | the fixed versions in a private include directory. There is a possibility that,
|
---|
68 | as a result of this process, some header files from the host system have found
|
---|
69 | their way into GCC's private include dir. As the rest of this chapter only
|
---|
70 | requires the headers from GCC and Glibc, which have both been installed at this
|
---|
71 | point, any "fixed" headers can safely be removed. This helps to avoid
|
---|
72 | any host headers polluting the build environment. Run the following commands to
|
---|
73 | remove the header files in GCC's private include directory (you may find it
|
---|
74 | easier to copy and paste these commands, rather than typing them by hand, due to
|
---|
75 | their length):</para>
|
---|
76 |
|
---|
77 | <!-- && used to ease copy and pasting -->
|
---|
78 | <screen><userinput>GCC_INCLUDEDIR=`dirname $(gcc -print-libgcc-file-name)`/include &&
|
---|
79 | find ${GCC_INCLUDEDIR}/* -maxdepth 0 -xtype d -exec rm -rf '{}' \; &&
|
---|
80 | rm -vf `grep -l "DO NOT EDIT THIS FILE" ${GCC_INCLUDEDIR}/*` &&
|
---|
81 | unset GCC_INCLUDEDIR</userinput></screen>
|
---|
82 |
|
---|
83 | <caution><para>At this point, it is imperative to stop and ensure that
|
---|
84 | the basic functions (compiling and linking) of the new toolchain are
|
---|
85 | working as expected. To perform a sanity check, run the following
|
---|
86 | commands:</para>
|
---|
87 |
|
---|
88 | <screen><userinput>echo 'main(){}' > dummy.c
|
---|
89 | cc dummy.c
|
---|
90 | readelf -l a.out | grep ': /tools'</userinput></screen>
|
---|
91 |
|
---|
92 | <para>If everything is working correctly, there should be no errors,
|
---|
93 | and the output of the last command will be of the form:</para>
|
---|
94 |
|
---|
95 | <screen><computeroutput>[Requesting program interpreter:
|
---|
96 | /tools/lib/ld-linux.so.2]</computeroutput></screen>
|
---|
97 |
|
---|
98 | <para>Note that <filename class="directory">/tools/lib</filename>
|
---|
99 | appears as the prefix of the dynamic linker.</para>
|
---|
100 |
|
---|
101 | <para>If the output is not shown as above or there was no output at
|
---|
102 | all, then something is wrong. Investigate and retrace the steps to
|
---|
103 | find out where the problem is and correct it. This issue must be
|
---|
104 | resolved before continuing on. First, perform the sanity check again,
|
---|
105 | using <command>gcc</command> instead of <command>cc</command>. If this
|
---|
106 | works, then the <filename class="symlink">/tools/bin/cc</filename> symlink is missing.
|
---|
107 | Revisit <xref linkend="ch-tools-gcc-pass1" role=","/> and install the symlink.
|
---|
108 | Next, ensure that the <envar>PATH</envar> is correct. This can be checked by running
|
---|
109 | <command>echo $PATH</command> and verifying that <filename
|
---|
110 | class="directory">/tools/bin</filename> is at the head of the list. If
|
---|
111 | the <envar>PATH</envar> is wrong it could mean that you are not logged in as user
|
---|
112 | <emphasis>lfs</emphasis> or that something went wrong back in <xref
|
---|
113 | linkend="ch-tools-settingenviron" role="."/> Another option is that something
|
---|
114 | may have gone wrong with the specs file amendment above. In this case,
|
---|
115 | redo the specs file amendment, being careful to copy-and-paste the
|
---|
116 | commands.</para>
|
---|
117 |
|
---|
118 | <para>Once all is well, clean up the test files:</para>
|
---|
119 |
|
---|
120 | <screen><userinput>rm -v dummy.c a.out</userinput></screen>
|
---|
121 | </caution>
|
---|
122 |
|
---|
123 | </sect1>
|
---|
124 |
|
---|