source: chapter06/adjustingtoolchain.xml@ 076ddfe

10.0 10.0-rc1 10.1 10.1-rc1 11.0 11.0-rc1 11.0-rc2 11.0-rc3 11.1 11.1-rc1 11.2 11.2-rc1 11.3 11.3-rc1 12.0 12.0-rc1 12.1 12.1-rc1 6.0 6.1 6.1.1 6.3 6.4 6.5 6.6 6.7 6.8 7.0 7.1 7.2 7.3 7.4 7.5 7.5-systemd 7.6 7.6-systemd 7.7 7.7-systemd 7.8 7.8-systemd 7.9 7.9-systemd 8.0 8.1 8.2 8.3 8.4 9.0 9.1 arm bdubbs/gcc13 ml-11.0 multilib renodr/libudev-from-systemd s6-init trunk v5_0 v5_1 v5_1_1 xry111/arm64 xry111/arm64-12.0 xry111/clfs-ng xry111/lfs-next xry111/loongarch xry111/loongarch-12.0 xry111/loongarch-12.1 xry111/mips64el xry111/pip3 xry111/rust-wip-20221008 xry111/update-glibc
Last change on this file since 076ddfe was e4df1fc, checked in by Greg Schafer <greg@…>, 21 years ago

Add more clarifying notes.

git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@2917 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689

  • Property mode set to 100644
File size: 4.0 KB
Line 
1<sect1 id="ch06-adjustingtoolchain">
2<title>Re-adjusting the toolchain</title>
3<?dbhtml filename="adjustingtoolchain.html" dir="chapter06"?>
4
5<para>Now that the new C libraries have been installed, it's time to re-adjust
6our toolchain. We'll adjust it so that it will link any newly compiled program
7against the new C libraries. Basically, this is the reverse of what we did
8in the "Locking in" stage in the beginning of the previous chapter.</para>
9
10<para>The first thing to do is to adjust the linker. For this we retained the
11source and build directories from the second pass over Binutils. Install the
12adjusted linker by running the following from within the
13<filename class="directory">binutils-build</filename> directory:</para>
14
15<para><screen><userinput>make -C ld INSTALL=/tools/bin/install install</userinput></screen></para>
16
17<note><para>If you somehow missed the earlier warning to retain the Binutils
18source and build directories from the second pass in Chapter 5 or otherwise
19accidentally deleted them or just don't have access to them, don't worry, all is
20not lost. Just ignore this step. The result will be that the next package,
21Binutils, will link against the Glibc libraries in
22<filename class="directory">/tools</filename> rather than
23<filename class="directory">/usr</filename>. This is not ideal, however, our
24testing has shown that the resulting Binutils program binaries should be
25identical.</para></note>
26
27<para>From now on every compiled program will link <emphasis>only</emphasis>
28against the libraries in <filename>/usr/lib</filename> and
29<filename>/lib</filename>. The extra
30<userinput>INSTALL=/tools/bin/install</userinput> is needed because the Makefile
31created during the second pass still contains the reference to
32<filename>/usr/bin/install</filename>, which we obviously haven't installed yet.
33Some host distributions contain a <filename class="symlink">ginstall</filename>
34symbolic link which takes precedence in the Makefile and thus can cause a
35problem here. The above command takes care of this also.</para>
36
37<para>You can now remove the Binutils source and build directories.</para>
38
39<para>The next thing to do is to amend our GCC specs file so that it points
40to the new dynamic linker. Just like earlier on, we use a sed to accomplish
41this:</para>
42
43<para><screen><userinput>SPECFILE=/tools/lib/gcc-lib/*/*/specs
44sed -e 's@/tools/lib/ld.so.1@/lib/ld.so.1@g' \
45&nbsp;&nbsp;&nbsp;&nbsp;-e 's@/tools/lib/ld-linux.so.2@/lib/ld-linux.so.2@g' \
46&nbsp;&nbsp;&nbsp;&nbsp;$SPECFILE > newspecfile
47mv newspecfile $SPECFILE
48unset SPECFILE</userinput></screen></para>
49
50<para>Again, cutting and pasting the above is recommended. And just like
51before, it is a good idea to check the specs file to ensure the intended
52changes were actually made.</para>
53
54<caution><para>It is imperative at this point to stop and ensure that the
55basic functions (compiling and linking) of the adjusted toolchain are working
56as expected. For this we are going to perform a simple sanity check:</para>
57
58<para><screen><userinput>echo 'main(){}' > dummy.c
59gcc dummy.c
60readelf -l a.out | grep ': /lib'</userinput></screen></para>
61
62<para>If everything is working correctly, there should be no errors, and the
63output of the last command will be:</para>
64
65<blockquote><screen>[Requesting program interpreter: /lib/ld-linux.so.2]</screen></blockquote>
66
67<para>If you did not receive the output as shown above, then something is
68seriously wrong. You will need to investigate and retrace your steps to find
69out where the problem is and correct it. There is no point in continuing
70until this is done. Most likely something went wrong with the specs file
71amendment above. Note especially that <filename>/lib</filename> now appears as
72the prefix of our dynamic linker. Of course, if you are working on a platform
73where the name of the dynamic linker is something other than
74<filename>ld-linux.so.2</filename>, then the output will be slightly
75different.</para>
76
77<para>Once you are satisfied that all is well, clean up the test files:</para>
78
79<para><screen><userinput>rm dummy.c a.out</userinput></screen></para>
80</caution>
81
82</sect1>
83
Note: See TracBrowser for help on using the repository browser.