Changeset a0b689e for chapter06/chapter06.xml

Timestamp:

02/11/2004 10:02:32 PM (20 years ago)

Author:

Alex Gronenwoud <alex@…>

Branches:

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_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

Children:

cd1ddd7

Parents:

c91dd5b

Message:

Adapting the title of the 'Locking in' section.

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

File:

• chapter06/chapter06.xml (modified) (2 diffs)

chapter06/chapter06.xml

@@ -358 +358 @@
 
 
-<sect1 id="ch-system-adjustingtoolchain">
+<sect1 id="ch-system-readjusting">
 <title>Re-adjusting the toolchain</title>
-<?dbhtml filename="adjustingtoolchain.html" dir="chapter06"?>
-
-<para>Now that the new C libraries have been installed, it's time to re-adjust
-our toolchain. We'll adjust it so that it will link any newly compiled program
-against the new C libraries. Basically, this is the reverse of what we did
-in the "locking in" stage in the beginning of the previous chapter.</para>
-
-<para>The first thing to do is to adjust the linker. For this we retained the
+<?dbhtml filename="readjusting.html" dir="chapter06"?>
+
+<para>Now that the new and final C libraries have been installed, it's time to
+adjust our toolchain again. We'll adjust it so that it will link any newly
+compiled program against these new libraries. This is in fact the same we did
+in the "Adjusting" phase in the beginning of the previous chapter, even though
+it looks like the reverse: then we guided the chain from the host's
+<filename class="directory">{,/usr}/lib</filename> to the new
+<filename class="directory">/tools/lib</filename>, now we guide it from that
+same <filename class="directory">/tools/lib</filename>
+to the LFS's <filename class="directory">{,/usr}/lib</filename>.</para>
+
+<para>First we adjust the linker. For this we retained the
 source and build directories from the second pass over Binutils. Install the
 adjusted linker by running the following from within the
@@ -379 +384 @@
 don't have access to them, don't worry, all is not lost. Just ignore the above
 command. The result will be that the next package, Binutils, will link against
-the Glibc libraries in <filename class="directory">/tools</filename> rather
-than <filename class="directory">/usr</filename>. This is not ideal, however,
-our testing has shown that the resulting Binutils program binaries should be
-identical.</para></note>
+the C libraries in <filename class="directory">/tools</filename> rather
+than <filename class="directory">{,/usr}/lib</filename>. This is not ideal,
+however, our testing has shown that the resulting Binutils program binaries
+should be identical.</para></note>
 
 <para>From now on every compiled program will link <emphasis>only</emphasis>