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
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
|
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
<!ENTITY % general-entities SYSTEM "../general.ent">
%general-entities;
]>
<sect1 id="ch-tools-adjusting">
<title>Adjusting the Toolchain</title>
<?dbhtml filename="adjusting.html"?>
<para>Now that the temporary C libraries have been installed, all
tools compiled in the rest of this chapter should be linked against
these libraries. In order to accomplish this, the linker and the
compiler's specs file need to be adjusted.</para>
<para>The linker, adjusted at the end of the first pass of Binutils,
is installed by running the following command from within the
<filename class="directory">binutils-build</filename> directory:</para>
<screen><userinput>make -C ld install</userinput></screen>
<para>From this point onwards, everything will link only
against the libraries in <filename class="directory">/tools/lib</filename>.</para>
<note><para>If the earlier warning to retain the Binutils source and
build directories from the first pass was missed, ignore the above
command. This results in a small chance that the subsequent testing
programs will link against libraries on the host. This is not ideal,
but it is not a major problem. The situation is corrected when the
second pass of Binutils is installed later.</para></note>
<para>Now that the adjusted linker is installed, the Binutils build and source
directories should be removed.</para>
<para>The next task is to point GCC to the new dynamic linker. This is done by
dumping GCC's <quote>specs</quote> file to a location where GCC will look for it
by default. A simple <command>sed</command> substitution then alters the
dynamic linker that GCC will use:</para>
<!-- Ampersands are needed to allow copy and paste -->
<screen><userinput>SPECFILE=`dirname $(gcc -print-libgcc-file-name)`/specs &&
gcc -dumpspecs > $SPECFILE &&
sed 's@^/lib/ld-linux.so.2@/tools&@g' $SPECFILE > tempspecfile &&
mv -f tempspecfile $SPECFILE &&
unset SPECFILE</userinput></screen>
<para>It is recommended that the above
command be copy-and-pasted in order to ensure accuracy.
Alternatively, the specs file can be edited by hand. This is done by
replacing every occurrence of <quote>/lib/ld-linux.so.2</quote> with
<quote>/tools/lib/ld-linux.so.2</quote></para>
<para>Be sure to visually inspect the specs file in order to verify the
intended changes have been made.</para>
<important><para>If working on a platform where the name of the
dynamic linker is something other than
<filename class="libraryfile">ld-linux.so.2</filename>, replace
<quote>ld-linux.so.2</quote> with the name of the platform's
dynamic linker in the above commands. Refer back to <xref
linkend="ch-tools-toolchaintechnotes" role=","/> if
necessary.</para></important>
<para>There is a possibility that some header files from the host system have
found their way into GCC's private include dir. This can happen as a result of
GCC's <quote>fixincludes</quote> process, which runs as part of the GCC build.
This is explained in more detail later in this chapter. Run the following commands to remove those header files (you may find it easier to copy and paste these commands, rather than typing them by hand, due to their length):</para>
<!-- && used to ease copy and pasting -->
<screen><userinput>GCC_INCLUDEDIR=`dirname $(gcc -print-libgcc-file-name)`/include &&
find ${GCC_INCLUDEDIR}/* -maxdepth 0 -xtype d -exec rm -rf '{}' \; &&
rm -f `grep -l "DO NOT EDIT THIS FILE" ${GCC_INCLUDEDIR}/*` &&
unset GCC_INCLUDEDIR</userinput></screen>
<caution><para>At this point, it is imperative to stop and ensure that
the basic functions (compiling and linking) of the new toolchain are
working as expected. To perform a sanity check, run the following
commands:</para>
<screen><userinput>echo 'main(){}' > dummy.c
cc dummy.c
readelf -l a.out | grep ': /tools'</userinput></screen>
<para>If everything is working correctly, there should be no errors,
and the output of the last command will be of the form:</para>
<screen><computeroutput>[Requesting program interpreter:
/tools/lib/ld-linux.so.2]</computeroutput></screen>
<para>Note that <filename class="directory">/tools/lib</filename>
appears as the prefix of the dynamic linker.</para>
<para>If the output is not shown as above or there was no output at
all, then something is wrong. Investigate and retrace the steps to
find out where the problem is and correct it. This issue must be
resolved before continuing on. First, perform the sanity check again,
using <command>gcc</command> instead of <command>cc</command>. If this
works, then the <filename class="symlink">/tools/bin/cc</filename> symlink is missing.
Revisit <xref linkend="ch-tools-gcc-pass1" role=","/> and install the symlink.
Next, ensure that the <envar>PATH</envar> is correct. This can be checked by running
<command>echo $PATH</command> and verifying that <filename
class="directory">/tools/bin</filename> is at the head of the list. If
the <envar>PATH</envar> is wrong it could mean that you are not logged in as user
<emphasis>lfs</emphasis> or that something went wrong back in <xref
linkend="ch-tools-settingenviron" role="."/> Another option is that something
may have gone wrong with the specs file amendment above. In this case,
redo the specs file amendment, being careful to copy-and-paste the
commands.</para>
<para>Once all is well, clean up the test files:</para>
<screen><userinput>rm dummy.c a.out</userinput></screen>
</caution>
</sect1>
|
