Adding several cross reference tags.

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

appendixa/appendixa.xml

@@ -1,4 +1,4 @@
-<appendix id="appendixa">
+<appendix id="appendixa" xreflabel="Appendix A">
 <title>Package descriptions and dependencies</title>
 <?dbhtml filename="appendixa.html" dir="appendixa"?>
 

appendixb/appendixb.xml

@@ -1,4 +1,4 @@
-<appendix id="appendixb">
+<appendix id="appendixb" xreflabel="Appendix B">
 <title>Index of programs and library files</title>
 <?dbhtml filename="appendixb.html" dir="appendixb"?>
 

chapter01/changelog.xml

@@ -101,6 +101,9 @@ the <filename>/etc/lfs</filename> filename to
 <filename>/etc/lfs-release</filename> to be more consistent with other
 distributions out there.</para></listitem>
 
+<listitem><para>October 23rd, 2003 [alex]: Changed most of the "Chapter"
+references to proper "xref" cross references .</para></listitem>
+
 <listitem><para>October 22nd, 2003 [gerard] Chapter 2: Added notes how to
 create installation dependency lists.</para></listitem>
 
@@ -416,11 +419,11 @@ used in the gzip installation.  Closes bug 551.</para></listitem>
 patches: Added a note regarding Tushar's patches project, and a link
 to the patches home page.</para></listitem>
 
-<listitem><para>September 3rd, 2003 [matt]: Fixed issue with util-linux not
+<listitem><para>September 3rd, 2003 [matt]: Fixed issue with Util-linux not
 utilizing headers and libraries installed in /stage1.</para></listitem>
 
 <listitem><para>September 3rd, 2003 [matt]: Removed "rm /bin/pwd" instruction
-from chapter06 kernel-headers installation as the link is still required by
+from Chapter 6 kernel-headers installation as the link is still required by
 Glibc's installation.</para></listitem>
 
 <listitem><para>September 2nd, 2003 [alex]: Adjusted all the SBUs from the

chapter01/chapter01.xml

@@ -1,4 +1,4 @@
-<chapter id="chapter01">
+<chapter id="chapter01" xreflabel="Chapter 1">
 <title>Introduction</title>
 <?dbhtml filename="chapter01.html" dir="chapter01"?>
 

chapter01/how.xml

@@ -9,60 +9,62 @@ programs like a compiler, linker and shell to build the new system. Normally
 all the required tools are available if you selected <quote>development</quote>
 as one of the options when you installed your distribution.</para>
 
-<para>In Chapter 3 you will first create a new Linux native partition and file
-system, the place where your new LFS system will be compiled and installed. Then
-in Chapter 4 you download all the packages and patches required to build an LFS
-system, and store them on the new file system.</para>
+<para>In <xref linkend="chapter03"/> you will first create a new Linux native
+partition and file system, the place where your new LFS system will be compiled
+and installed. Then in <xref linkend="chapter04"/> you download all the
+packages and patches required to build an LFS system, and store them on the new
+file system.</para>
 
-<para>Chapter 5 will then discuss the installation of a number of packages that
-will form the basic development suite (or toolchain) which is used to build the
-actual system in Chapter 6. Some of these packages are needed to resolve
-circular dependencies. For example, to compile a compiler you need a
-compiler.</para>
+<para><xref linkend="chapter05"/> then discusses the installation of a number
+of packages that will form the basic development suite (or toolchain) which is
+used to build the actual system in <xref linkend="chapter06"/>. Some of these
+packages are needed to resolve circular dependencies -- for example, to compile
+a compiler you need a compiler.</para>
 
-<para>The first thing to be done in Chapter 5 is build a first pass of the 
-toolchain, which is made up of Binutils and GCC. The programs from these 
-packages will be linked statically in order for them to be used independently 
-of the host system. The second thing to do is build Glibc, the C library. Glibc 
-will be compiled by the toolchain programs we just built in the first 
-pass. The third thing to do is build a second pass of the toolchain. This time
-the toolchain will be dynamically linked against the newly built Glibc. The
-remaining Chapter 5 packages are all built using this second pass toolchain and
-dynamically linked against the new host-independent Glibc. When this is done,
-the LFS installation process will no longer depend on the host distribution,
-with the exception of the running kernel.</para>
+<para>The first thing to be done in <xref linkend="chapter05"/> is build a
+first pass of the toolchain, made up of Binutils and GCC. The programs from
+these  packages will be linked statically in order for them to be usable
+independently of the host system. The second thing to do is build Glibc, the
+C library. Glibc will be compiled by the toolchain programs we just built in
+the first pass. The third thing to do is build a second pass of the toolchain.
+This time the toolchain will be dynamically linked against the newly built
+Glibc. The remaining <xref linkend="chapter05"/> packages are all built using
+this second pass toolchain and dynamically linked against the new
+host-independent Glibc. When this is done, the LFS installation process will no
+longer depend on the host distribution, with the exception of the running
+kernel.</para>
 
-<para>You may be asking yourself <quote>that seems like a lot of work, just to
-get away from my host distribution?</quote>. A full technical and in-depth
-explanation is provided at the start of Chapter 5, including some notes on the
-differences between statically and dynamically linked programs.</para>
+<para>You may be thinking that <quote>this seems like a lot of work, just to
+get away from my host distribution</quote>. Well, a full technical explanation
+is provided at the start of <xref linkend="chapter05"/>, including some notes
+on the differences between statically and dynamically linked programs.</para>
 
-<para>In Chapter 6 your real LFS system will be built. The chroot (change root) 
-program is used to enter a virtual environment and start a new shell whose root 
-directory will be set to the LFS partition. This is very similar to rebooting 
-and instructing the kernel to mount the LFS partition as the root partition. 
-The reason that you don't actually reboot, but instead chroot, is that creating 
-a bootable system requires additional work which isn't necessary just yet.
-Another advantage is that chrooting allows you to continue using the host while
-LFS is being built. While waiting for package compilation to complete, you can
-simply switch to a different VC (Virtual Console) or X desktop and continue
-using the computer as you normally would.</para>
+<para>In <xref linkend="chapter06"/> your real LFS system will be built. The
+chroot (change root)  program is used to enter a virtual environment and start
+a new shell whose root directory will be set to the LFS partition. This is very
+similar to rebooting and instructing the kernel to mount the LFS partition as
+the root partition. The reason that you don't actually reboot, but instead
+chroot, is that creating a bootable system requires additional work which isn't
+necessary just yet. But the major advantage is that chrooting allows you to
+continue using the host while LFS is being built. While waiting for package
+compilation to complete, you can simply switch to a different VC (Virtual
+Console) or X desktop and continue using the computer as you normally
+would.</para>
 
-<para>When all the software from Chapter 6 is installed, the temporary tools 
-built in Chapter 5 are removed. In Chapters 7, 8 and 9 the installation will
-then be finalized. The bootscripts are set up in Chapter 7, the kernel and
-bootloader are set up in Chapter 8, and Chapter 9 has some pointers to help
-you after you finish the book.  Then, finally, you're ready to reboot your
-computer into your new LFS system.</para>
+<para>To finish the installation, the bootscripts are set up in
+<xref linkend="chapter07"/>, the kernel and bootloader are set up in
+<xref linkend="chapter08"/>, and <xref linkend="chapter09"/> contains some
+pointers to help you after you finish the book.  Then, finally, you're ready to
+reboot your computer into your new LFS system.</para>
 
 <para>This is the process in a nutshell. Detailed information on the steps you 
 will take are discussed in the chapters and package descriptions as you 
 progress through them. If something isn't completely clear now, don't worry, 
 everything will fall into place soon.</para>
 
-<para>Please read Chapter 2 carefully as it explains a few important things you 
-should be aware of before you begin to work through Chapters 5 and 
-beyond.</para>
+<para>Please read <xref linkend="chapter02"/> carefully as it explains a few
+important things you should be aware of before you begin to work through
+<xref linkend="chapter05"/> and beyond.</para>
 
 </sect1>
 

chapter02/aboutlfs.xml

@@ -6,8 +6,8 @@
 variable LFS will be used frequently. $LFS must at all times be replaced with
 the directory where the partition that contains the LFS system is mounted. How
 to create and where to mount the partition will be explained in full detail in
-Chapter 3. For the moment let's assume that the LFS partition is mounted on
-<filename>/mnt/lfs</filename>.</para>
+<xref linkend="chapter03"/>. For the moment let's assume that the LFS partition
+is mounted on <filename>/mnt/lfs</filename>.</para>
 
 <para>When you are told to run a command like
 <userinput>./configure --prefix=$LFS/tools</userinput>, you actually have to

chapter02/chapter02.xml

@@ -1,4 +1,4 @@
-<chapter id="chapter02">
+<chapter id="chapter02" xreflabel="Chapter 2">
 <title>Important information</title>
 <?dbhtml filename="chapter02.html" dir="chapter02"?>
 

chapter03/chapter03.xml

@@ -1,4 +1,4 @@
-<chapter id="chapter03">
+<chapter id="chapter03" xreflabel="Chapter 3">
 <title>Preparing a new partition</title>
 <?dbhtml filename="chapter03.html" dir="chapter03"?>
 

chapter04/chapter04.xml

@@ -1,4 +1,4 @@
-<chapter id="chapter04">
+<chapter id="chapter04" xreflabel="Chapter 4">
 <title>The materials: packages and patches</title>
 <?dbhtml filename="chapter04.html" dir="chapter04"?>
 

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>

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"?>
 

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>
 

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

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

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>
 

chapter06/aboutdebug.xml

@@ -41,9 +41,9 @@ or ELF binary), run <userinput>strip --strip-debug filename</userinput>.
 Wildcards can be used to treat multiple files (use something like
 <userinput>strip --strip-debug $LFS/tools/bin/*</userinput>).</para>
 
-<para>For your convenience, Chapter 9 includes one simple command to strip
-all debugging symbols from all programs and libraries on your system.
-Additional information on optimization can be found in the hint at
+<para>For your convenience, <xref linkend="chapter09"/> includes one simple
+command to strip all debugging symbols from all programs and libraries on your
+system. Additional information on optimization can be found in the hint at
 <ulink url="&hints-root;optimization.txt"/>.</para>
 
 </sect1>

chapter06/bootscripts-inst.xml

@@ -10,7 +10,8 @@ scripts, to be found at <ulink url="&hints-root;bsd-init.txt"/>. And if you'd
 like something more radical, search the LFS mailing lists for depinit.</para>
 
 <para>If you decide to use BSD style, or some other style scripts, you can
-skip Chapter 7 when you arrive at it and move on to Chapter 8.</para>
+skip the next chapter when you arrive at it and move on to
+<xref linkend="chapter08"/>.</para>
 
 <para>Install the boot scripts:</para>
 

chapter06/chapter06.xml

@@ -1,4 +1,4 @@
-<chapter id="chapter06">
+<chapter id="chapter06" xreflabel="Chapter 6">
 <title>Installing basic system software</title>
 <?dbhtml filename="chapter06.html" dir="chapter06"?>
 

chapter06/gcc-2953-inst.xml

@@ -10,7 +10,8 @@ default optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting
 or modifying them when building GCC.</para>
 
 <para>This is an older release of GCC which we are going to install for the
-purpose of compiling the Linux kernel in Chapter 8. This version is recommended
+purpose of compiling the Linux kernel in <xref linkend="chapter08"/>. This
+version is recommended
 by the kernel developers when you need absolute stability. Later versions of
 GCC have not received as much testing for Linux kernel compilation. Using a
 later version is likely to work, however, we recommend adhering to the kernel

chapter06/procps-inst.xml

@@ -3,7 +3,7 @@
 <sect2>
 <title>Installation of Procps</title>
 
-<para>First fix a locale problem that can crash <userinput>w</userinput> under
+<para>First fix a problem that can crash <userinput>w</userinput> under
 certain locale settings:</para>
 
 <screen><userinput>patch -Np1 -i ../&procps-patch;</userinput></screen>

chapter07/chapter07.xml

@@ -1,4 +1,4 @@
-<chapter id="chapter07">
+<chapter id="chapter07" xreflabel="Chapter 7">
 <title>Setting up system boot scripts</title>
 <?dbhtml filename="chapter07.html" dir="chapter07"?>
 

chapter07/loadkeys.xml

@@ -2,13 +2,13 @@
 <title>Do I need the loadkeys script?</title>
 <?dbhtml filename="loadkeys.html" dir="chapter07"?>
 
-<para>If you decided to compile your keymap file directly into the kernel
-back at the end of Chapter 6, then you strictly speaking don't need to run
-this loadkeys script, since the kernel has already set up the keymap for
-you. You can still run it if you want, it isn't going to hurt you. It could
-even be beneficial to keep it in case you run a lot of different kernels
-and don't remember or want to compile the keymap into every kernel you lay
-your hands on.</para>
+<para>If you decided to compile your keymap file directly into the kernel back
+at the end of <xref linkend="chapter06"/>, then you strictly speaking don't
+need to run this loadkeys script, since the kernel has already set up the
+keymap for you. You can still run it if you want, it isn't going to hurt you.
+It could even be beneficial to keep it in case you run a lot of different
+kernels and don't remember or want to compile the keymap into every kernel you
+lay your hands on.</para>
 
 <para>If you decided you don't need to, or don't want to use the loadkeys
 script, remove the

chapter08/chapter08.xml

@@ -1,4 +1,4 @@
-<chapter id="chapter08">
+<chapter id="chapter08" xreflabel="Chapter 8">
 <title>Making the LFS system bootable</title>
 <?dbhtml filename="chapter08.html" dir="chapter08"?>
 

chapter09/chapter09.xml

@@ -1,4 +1,4 @@
-<chapter id="chapter09">
+<chapter id="chapter09" xreflabel="Chapter 9">
 <title>The End</title>
 <?dbhtml filename="chapter09.html" dir="chapter09"?>