blob: 7938df87934f0b8bfafd86bf9e27d0046e66ce27 (
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
|
<sect1 id="ch05-locking-glibc">
<title>"Locking in" Glibc</title>
<?dbhtml filename="lockingglibc.html" dir="chapter05"?>
<para>Now that the temporary C libraries have been installed, we want all
the tools compiled in the rest of this chapter to be linked against these
libraries. To accomplish this, we need to adjust the linker's scripts and the
compiler's specs file.</para>
<para>First 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>These scripts were adjusted a little while back, at the end of the first
pass of Binutils, and contain no mention of <filename>/lib</filename>,
<filename>/usr/lib</filename> or <filename>/usr/local/lib</filename>.
From this point onwards everything will link <emphasis>only</emphasis>
against the libraries in <filename>/tools/lib</filename>.</para>
<para>Now that the scripts are adjusted, you have to remove the Binutils
build and source directories.</para>
<para>The next thing to do is to amend our GCC specs file so that it points
to the new dynamic linker. A simple sed will accomplish this:</para>
<para><screen><userinput>SPECFILE=/tools/lib/gcc-lib/*/*/specs
sed -e 's@/lib/ld.so.1@/tools/lib/ld.so.1@g' \
-e 's@/lib/ld-linux.so.2@/tools/lib/ld-linux.so.2@g' \
$SPECFILE > tempspecfile
mv tempspecfile $SPECFILE
unset SPECFILE</userinput></screen></para>
<para>We recommend that you cut-and-paste the above rather than try and type it
all in. Or you can edit the specs file by hand if you want to: just replace
"/lib/ld-linux.so.2" with "/tools/lib/ld-linux.so.2" and "/lib/ld.so.1" with
"/tools/lib/ld.so.1".</para>
<para>Lastly, there is a possibility that some include files from the host
system have found their way into gcc's private include dir. This can happen
because of GCC's "fixincludes" process which runs as part of the GCC build.
We'll explain more about this further on in this chapter. For now, run the
following commands to eliminate this possibility.</para>
<para><screen><userinput>rm -f /tools/lib/gcc-lib/*/*/include/{pthread.h,bits/sigthread.h}</userinput></screen></para>
<para>This completes the installation of the self-contained toolchain, which
can now be used to build the rest of the temporary tools.</para>
</sect1>
|