Adding several cross reference tags.

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

6 files changed, 56 insertions, 46 deletions

diff --git a/chapter05/binutils-pass2-inst.xml b/chapter05/binutils-pass2-inst.xml
index c37070167..55d61844e 100644
--- a/chapter05/binutils-pass2-inst.xml
+++ b/chapter05/binutils-pass2-inst.xml
@@ -30,7 +30,8 @@ variables that override the default optimization flags.</para>
 <screen><userinput>make </userinput></screen>
 
 <note><para>It's worth pointing out that running the Binutils test suite here
-is considered not as important as running it in Chapter 6.</para></note>
+is considered not as important as running it in
+<xref linkend="chapter06"/>.</para></note>
 
 <para>Test the results (there should be no unexpected failures here, expected
 failures are fine):</para>
diff --git a/chapter05/chapter05.xml b/chapter05/chapter05.xml
index fd4d1d65a..44cbf189f 100644
--- a/chapter05/chapter05.xml
+++ b/chapter05/chapter05.xml
@@ -1,4 +1,4 @@
-<chapter id="chapter05">
+<chapter id="chapter05" xreflabel="Chapter 5">
 <title>Constructing a temporary system</title>
 <?dbhtml filename="chapter05.html" dir="chapter05"?>
 
diff --git a/chapter05/gcc-pass2-inst.xml b/chapter05/gcc-pass2-inst.xml
index 08b3b6d33..cd3d4505a 100644
--- a/chapter05/gcc-pass2-inst.xml
+++ b/chapter05/gcc-pass2-inst.xml
@@ -38,11 +38,12 @@ briefly earlier, but a slightly more in-depth explanation of the fixincludes
 process is warranted here.  Under normal circumstances, the GCC fixincludes
 script scans your system for header files that need to be fixed.  It might find
 that some Glibc header files on your host system need to be fixed, fix them and
-put them in the GCC private include directory.  Then, later on in Chapter 6,
-after we've installed the newer Glibc, this private include directory would be
-searched before the system include directory, resulting in GCC finding the
-fixed headers from the host system, which would most likely not match the Glibc
-version actually used for the LFS system.</para>
+put them in the GCC private include directory.  Then, later on in
+<xref linkend="chapter06"/>, after we've installed the newer Glibc, this
+private include directory would be searched before the system include
+directory, resulting in GCC finding the fixed headers from the host system,
+which would most likely not match the Glibc version actually used for the LFS
+system.</para>
 
 <para>The last patch changes GCC's default location of the dynamic linker
 (typically <filename>ld-linux.so.2</filename>). It also removes
@@ -105,7 +106,8 @@ as the compiler we're using to compile this GCC was built from the exact same
 version of the GCC sources we used earlier.</para>
 
 <note><para>It's worth pointing out that running the GCC test suite here
-is considered not as important as running it in Chapter 6.</para></note>
+is considered not as important as running it in
+<xref linkend="chapter06"/>.</para></note>
 
 <para>Test the results:</para>
 
diff --git a/chapter05/glibc-inst.xml b/chapter05/glibc-inst.xml
index 02da2d905..3e88212f1 100644
--- a/chapter05/glibc-inst.xml
+++ b/chapter05/glibc-inst.xml
@@ -9,8 +9,9 @@ Glibc-linuxthreads in that directory, not in the directory where you usually
 unpack all the sources.</para>
 
 <note><para>We are going to run the test suite for Glibc in this chapter.
-However, it's worth pointing out that running the Glibc test suite here 
-is considered not as important as running it in Chapter 6.</para></note>
+However, it's worth pointing out that running the Glibc test suite here
+is considered not as important as running it in
+<xref linkend="chapter06"/>.</para></note>
 
 <para>This package is known to behave badly when you have changed its
 default optimization flags (including the -march and -mcpu options).
@@ -89,13 +90,13 @@ running the test suite.</para>
 <screen><userinput>make check</userinput></screen>
 
 <para>The Glibc test suite is highly dependent on certain functions of your host
-system, in particular the kernel. Additionally, here in Chapter 5 some tests
+system, in particular the kernel. Additionally, here in this chapter some tests
 can be adversely affected by existing tools or environmental issues on the host
 system. Of course, these won't be a problem when we run the Glibc test suite
-inside the chroot environment of Chapter 6. In general, the Glibc test suite is
-always expected to pass. However, as mentioned above, some failures are
-unavoidable in certain circumstances. Here is a list of the most common issues
-we are aware of:</para>
+inside the chroot environment of <xref linkend="chapter06"/>. In general, the
+Glibc test suite is always expected to pass. However, as mentioned above, some
+failures are unavoidable in certain circumstances. Here is a list of the most
+common issues we are aware of:</para>
 
 <itemizedlist>
 <listitem><para>The <emphasis>math</emphasis> tests sometimes fail when running
@@ -118,10 +119,11 @@ the kernel.</para></listitem>
 fail due to test timeouts being exceeded.</para></listitem>
 </itemizedlist>
 
-<para>In summary, don't worry too much if you see Glibc test suite failures here
-in Chapter 5. The Glibc in Chapter 6 is the one we'll ultimately end up using so
-that is the one we would really like to see pass. But please keep in mind, even
-in Chapter 6 some failures could still occur -- the <emphasis>math</emphasis>
+<para>In summary, don't worry too much if you see Glibc test suite failures
+here in this chapter. The Glibc in <xref linkend="chapter06"/> is the one we'll
+ultimately end up using so that is the one we would really like to see pass.
+But please keep in mind, even in <xref linkend="chapter06"/> some failures
+could still occur -- the <emphasis>math</emphasis>
 tests for example. When experiencing a failure, make a note of it, then
 continue by reissuing the <userinput>make check</userinput>. The test suite
 should pick up where it left off and continue on. You can circumvent this
diff --git a/chapter05/tcl-inst.xml b/chapter05/tcl-inst.xml
index 1bd470550..c70070bf5 100644
--- a/chapter05/tcl-inst.xml
+++ b/chapter05/tcl-inst.xml
@@ -18,11 +18,11 @@ to know that our most important tools are working properly.</para>
 <screen><userinput>make</userinput></screen>
 
 <para>This package has a test suite available which can perform a number of
-checks to ensure it built correctly. However, the Tcl test suite here in
-Chapter 5 is known to experience failures under certain host conditions that
-are not fully understood. Therefore, test suite failures here are not
-surprising, but are not considered critical. Should you choose to run the test
-suite, the following command will do so:</para>
+checks to ensure it built correctly. However, the Tcl test suite in this
+chapter is known to experience failures under certain host conditions that are
+not fully understood. Therefore, test suite failures here are not surprising,
+but are not considered critical. Should you choose to run the test suite, the
+following command will do so:</para>
 
 <screen><userinput>TZ=UTC make test</userinput></screen>
 
@@ -33,7 +33,7 @@ suite, the following command will do so:</para>
 Coordinated Universal Time (UTC) also known as Greenwich Mean Time (GMT), but
 only for the duration of the test suite run. This ensures the clock tests are
 exercised correctly. More information on the TZ environment variable is
-available later on in Chapter 7.</para></listitem>
+available later on in <xref linkend="chapter07"/>.</para></listitem>
 </itemizedlist>
 
 <para>Sometimes, package test suites will give false failures.  You can
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>