Changeset 7f1fcd8 for chapter05/toolchaintechnotes.xml

Timestamp:

10/24/2003 05:28:42 PM (21 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_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

Children:

323ef74

Parents:

494f01f

Message:

Adding several cross reference tags.

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

File:

• chapter05/toolchaintechnotes.xml (modified) (5 diffs)

chapter05/toolchaintechnotes.xml

@@ -8 +8 @@
 an actual build. Feel free to refer back here at any time.</para>
 
-<para>The overall goal of Chapter 5 is to provide a sane, temporary environment
-that we can chroot into, and from which we can produce a clean, trouble-free
-build of the target LFS system in Chapter 6. Along the way, we attempt to
-divorce ourselves from the host system as much as possible, and in so doing
-build a self-contained and self-hosted toolchain. It should be noted that the
+<para>The overall goal of <xref linkend="chapter05"/> is to provide a sane,
+temporary environment that we can chroot into, and from which we can produce a
+clean, trouble-free build of the target LFS system in
+<xref linkend="chapter06"/>. Along the way, we attempt to divorce ourselves
+from the host system as much as possible, and in so doing build a
+self-contained and self-hosted toolchain. It should be noted that the
 build process has been designed in such a way so as to minimize the risks for
 new readers and provide maximum educational value at the same time. In other
@@ -45 +46 @@
 </important>
 
-<para>Some key technical points of how the Chapter 5 build method works:</para>
+<para>Some key technical points of how the <xref linkend="chapter05"/> build
+method works:</para>
 
 <itemizedlist>
@@ -129 +131 @@
 <userinput>'readelf -l &lt;name of binary&gt; | grep interpreter'</userinput>.
 By amending <userinput>gcc</userinput>'s specs file, we are ensuring that every
-program compiled from here through the end of Chapter 5 will use our new
-dynamic linker in <filename class="directory">/tools/lib</filename>.</para>
+program compiled from here through the end of <xref linkend="chapter05"/> will
+use our new dynamic linker in
+<filename class="directory">/tools/lib</filename>.</para>
 
 <para>The need to use the new dynamic linker is also the reason why we apply the
@@ -142 +145 @@
 <userinput>ld</userinput>'s library search path. From this point onwards, the
 core toolchain is self-contained and self-hosted. The remainder of the
-Chapter 5 packages all build against the new Glibc in
+<xref linkend="chapter05"/> packages all build against the new Glibc in
 <filename class="directory">/tools</filename> and all is well.</para>
 
-<para>Upon entering the chroot environment in Chapter 6, the first major package
-we install is Glibc, due to its self-sufficient nature that we mentioned above.
-Once this Glibc is installed into <filename class="directory">/usr</filename>,
-we perform a quick changeover of the toolchain defaults, then proceed for real
-in building the rest of the target Chapter 6 LFS system.</para>
+<para>Upon entering the chroot environment in <xref linkend="chapter06"/>, the
+first major package we install is Glibc, due to its self-sufficient nature that
+we mentioned above. Once this Glibc is installed into
+<filename class="directory">/usr</filename>, we perform a quick changeover of
+the toolchain defaults, then proceed for real in building the rest of the
+target <xref linkend="chapter06"/> LFS system.</para>
 
 <sect2>
@@ -181 +185 @@
 make use of the improved function.</para>
 
-<para>Why do we statically link the first two packages in Chapter 5? The reasons
-are threefold: historical, educational and technical. Historical because earlier
-versions of LFS statically linked every program in Chapter 5. Educational
-because knowing the difference is useful. Technical because we gain an element
-of independence from the host in doing so, i.e. those programs can be used
+<para>If dynamic linking has several advantages, why then do we statically link
+the first two packages in this chapter? The reasonsare threefold: historical,
+educational, and technical. Historical, because earlier versions of LFS
+statically linked every program in this chapter. Educational, because knowing
+the difference is useful. Technical, because we gain an element of independence
+from the host in doing so, meaning that those programs can be used
 independently of the host system. However, it's worth noting that an overall
-successful LFS build can still be achieved when the first two packages are built
-dynamically.</para>
+successful LFS build can still be achieved when the first two packages are
+built dynamically.</para>
 
 </sect2>