source: chapter06/readjusting.xml@ 456a1d92

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 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 456a1d92 was 2ec4b60, checked in by Zack Winkles <winkie@…>, 20 years ago

Normalized usage of sed throughout the book

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

  • Property mode set to 100644
File size: 4.8 KB
Line 
1<?xml version="1.0" encoding="ISO-8859-1"?>
2<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/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 new and final C libraries have been installed, it's time to
11adjust our toolchain again. We'll adjust it so that it will link any newly
12compiled program against these new libraries. This is in fact the same thing we
13did in the <quote>Adjusting</quote> phase in the beginning of the previous
14chapter, even though it looks like the reverse: then we guided the chain from
15the host's <filename class="directory">/{,usr/}lib</filename> to the new
16<filename class="directory">/tools/lib</filename>, now we guide it from that
17same <filename class="directory">/tools/lib</filename> to the LFS's <filename
18class="directory">/{,usr/}lib</filename>.</para>
19
20<para>First we adjust the linker. For this we retained the
21source and build directories from the second pass over Binutils. Install the
22adjusted linker by running the following from within the
23<filename class="directory">binutils-build</filename> directory:</para>
24
25<screen><userinput>make -C ld INSTALL=/tools/bin/install install</userinput></screen>
26
27<note><para>If you somehow missed the earlier warning to retain the Binutils
28source and build directories from the second pass in
29<xref linkend="chapter-temporary-tools"/>, or otherwise accidentally deleted them or just
30don't have access to them, don't worry, all is not lost. Just ignore the above
31command. The result will be that the next package, Binutils, will link against
32the C libraries in <filename class="directory">/tools</filename> rather
33than in <filename class="directory">/{,usr/}lib</filename>. This is not ideal,
34however, our testing has shown that the resulting Binutils program binaries
35should be identical.</para></note>
36
37<para>From now on every compiled program will link <emphasis>only</emphasis>
38against the libraries in <filename>/usr/lib</filename> and
39<filename>/lib</filename>. The extra
40<emphasis>INSTALL=/tools/bin/install</emphasis> is needed because the Makefile
41created during the second pass still contains the reference to
42<filename>/usr/bin/install</filename>, which we obviously haven't installed yet.
43Some host distributions contain a <filename class="symlink">ginstall</filename>
44symbolic link which takes precedence in the Makefile and thus can cause a
45problem here. The above command takes care of this also.</para>
46
47<para>You can now remove the Binutils source and build directories.</para>
48
49<para>The next thing to do is to amend our GCC specs file so that it points
50to the new dynamic linker. Just like earlier on, we use a sed to accomplish
51this:</para>
52
53<!-- Ampersands are needed to allow cut and paste -->
54
55<screen><userinput>sed -i 's@ /tools/lib/ld-linux.so.2@ /lib/ld-linux.so.2@g' \
56 `gcc --print-file specs`</userinput></screen>
57
58<para>Again, cutting and pasting the above is recommended. And just like
59before, it is a good idea to visually inspect the specs file to verify the
60intended change was actually made.</para>
61
62<important><para>If you are working on a platform where the name of the dynamic
63linker is something other than <filename>ld-linux.so.2</filename>, you
64<emphasis>must</emphasis> substitute <filename>ld-linux.so.2</filename> with the
65name of your platform's dynamic linker in the above commands. Refer back to
66<xref linkend="ch-tools-toolchaintechnotes"/> if necessary.</para></important>
67
68
69<caution><para>It is imperative at this point to stop and ensure that the
70basic functions (compiling and linking) of the adjusted toolchain are working
71as expected. For this we are going to perform a simple sanity check:</para>
72
73<screen><userinput>echo 'main(){}' &gt; dummy.c
74cc dummy.c
75readelf -l a.out | grep ': /lib'</userinput></screen>
76
77<para>If everything is working correctly, there should be no errors, and the
78output of the last command will be (allowing for platform specific differences
79in dynamic linker name):</para>
80
81<blockquote><screen>[Requesting program interpreter: /lib/ld-linux.so.2]</screen></blockquote>
82
83<para>Note especially that <filename class="directory">/lib</filename> is now
84the prefix of our dynamic linker.</para>
85
86<para> If you did not receive the output
87as shown above, or received no output at all, then something is seriously wrong.
88You will need to investigate and retrace your steps to find out where the
89problem is and correct it. There is no point in continuing until this is done.
90Most likely something went wrong with the specs file amendment above.</para>
91
92<para>Once you are satisfied that all is well, clean up the test files:</para>
93
94<screen><userinput>rm dummy.c a.out</userinput></screen>
95</caution>
96
97
98</sect1>
Note: See TracBrowser for help on using the repository browser.