Adding several cross reference tags.

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

1 files changed, 26 insertions, 21 deletions

diff --git a/chapter05/toolchaintechnotes.xml b/chapter05/toolchaintechnotes.xml
index 0b19468db..20f5ddc5c 100644
--- a/chapter05/toolchaintechnotes.xml
+++ b/chapter05/toolchaintechnotes.xml
@@ -7,11 +7,12 @@ details behind the overall build method. It's not essential that you understand
 everything here immediately. Most of it will make sense once you have performed
 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
 words, more advanced techniques could be used to build the system.</para>
@@ -44,7 +45,8 @@ the <filename>shlib-versions</filename> file in the root of the Glibc source
 tree.</para>
 </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>
 <listitem><para>Similar in principle to cross compiling whereby tools installed
@@ -128,8 +130,9 @@ hard-wired path to a dynamic linker is embedded into every ELF shared
 executable. You can inspect this by running:
 <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
 Specs patch for the second pass of GCC. Failure to do so will result in the GCC
@@ -141,14 +144,15 @@ would defeat our goal of getting away from the host.</para>
 <emphasis>--with-lib-path</emphasis> configure switch to control
 <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>
 <title>Notes on static linking</title>
@@ -180,14 +184,15 @@ library function gets a bug fixed or is otherwise improved, you only need to
 recompile this one library, instead of having to recompile all the programs that
 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>