Tagging corrections in chapters 5.

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

22 files changed, 102 insertions, 103 deletions

diff --git a/chapter05/adjusting.xml b/chapter05/adjusting.xml
index 1f18d7cb2..468241652 100644
--- a/chapter05/adjusting.xml
+++ b/chapter05/adjusting.xml
@@ -20,7 +20,7 @@ the <filename class="directory">binutils-build</filename> directory:</para>
 <screen><userinput>make -C ld install</userinput></screen>
 
 <para>From this point onwards everything will link <emphasis>only</emphasis>
-against the libraries in <filename>/tools/lib</filename>.</para>
+against the libraries in <filename class="directory">/tools/lib</filename>.</para>
 
 <note><para>If you somehow missed the earlier warning to retain the Binutils
 source and build directories from the first pass or otherwise accidentally
@@ -77,7 +77,7 @@ readelf -l a.out | grep ': /tools'</userinput></screen>
 output of the last command will be (allowing for platform specific differences
 in dynamic linker name):</para>
 
-<blockquote><screen>[Requesting program interpreter: /tools/lib/ld-linux.so.2]</screen></blockquote>
+<blockquote><screen><computeroutput>[Requesting program interpreter: /tools/lib/ld-linux.so.2]</computeroutput></screen></blockquote>
 
 <para>Note especially that <filename class="directory">/tools/lib</filename>
 appears as the prefix of our dynamic linker.</para>
diff --git a/chapter05/binutils-pass1.xml b/chapter05/binutils-pass1.xml
index b68d93fec..ae00bdc3d 100644
--- a/chapter05/binutils-pass1.xml
+++ b/chapter05/binutils-pass1.xml
@@ -32,8 +32,8 @@ because both Glibc and GCC perform various tests on the available linker and
 assembler to determine which of their own features to enable.</para>
 
 <para>This package is known to behave badly when you change its default
-optimization flags (including the <emphasis>-march</emphasis> and
-<emphasis>-mcpu</emphasis> options). Therefore, if you have defined any
+optimization flags (including the <parameter>-march</parameter> and
+<parameter>-mcpu</parameter> options). Therefore, if you have defined any
 environment variables that override default optimizations, such as CFLAGS and
 CXXFLAGS, we recommend un-setting them when building Binutils.</para>
 
@@ -58,13 +58,13 @@ like this: <userinput>time { ./configure ... &amp;&amp; ... &amp;&amp; ...
 
 <variablelist>
 <varlistentry>
-<term><userinput>--prefix=/tools</userinput></term>
+<term><parameter>--prefix=/tools</parameter></term>
 <listitem><para>This tells the configure script to prepare to install the Binutils
-programs in the <filename>/tools</filename> directory.</para></listitem>
+programs in the <filename class="directory">/tools</filename> directory.</para></listitem>
 </varlistentry>
 
 <varlistentry>
-<term><userinput>--disable-nls</userinput></term>
+<term><parameter>--disable-nls</parameter></term>
 <listitem><para>This disables internationalization (a word often shortened to 
 i18n). We don't need this for our static programs and <emphasis>nls</emphasis>
 often causes problems when linking statically.</para></listitem>
@@ -80,18 +80,18 @@ make LDFLAGS="-all-static"</userinput></screen>
 
 <variablelist>
 <varlistentry>
-<term><userinput>configure-host</userinput></term>
+<term><parameter>configure-host</parameter></term>
 <listitem><para>This forces all the subdirectories to be configured immediately. 
 A statically linked build will fail without it. We therefore use this option to work 
 around the problem.</para></listitem>
 </varlistentry>
 
 <varlistentry>
-<term><userinput>LDFLAGS="-all-static"</userinput></term>
+<term><parameter>LDFLAGS="-all-static"</parameter></term>
 <listitem><para>This tells the linker that all the Binutils programs should be 
-linked statically. However, strictly speaking, <emphasis>"-all-static"</emphasis> 
+linked statically. However, strictly speaking, <parameter>"-all-static"</parameter>
 is passed to the <command>libtool</command> program, which then passes
-<emphasis>"-static"</emphasis> to the linker.</para></listitem>
+<parameter>"-static"</parameter> to the linker.</para></listitem>
 </varlistentry>
 </variablelist>
 
@@ -114,14 +114,14 @@ make -C ld LDFLAGS="-all-static" LIB_PATH=/tools/lib</userinput></screen>
 
 <variablelist>
 <varlistentry>
-<term><userinput>-C ld clean</userinput></term>
+<term><parameter>-C ld clean</parameter></term>
 <listitem><para>This tells the make program to remove all the compiled files 
 in the <filename class="directory">ld</filename> subdirectory.</para></listitem>
 </varlistentry>
 
 <varlistentry>
-<term><userinput>-C ld LDFLAGS="-all-static" 
-LIB_PATH=/tools/lib</userinput></term>
+<term><parameter>-C ld LDFLAGS="-all-static"
+LIB_PATH=/tools/lib</parameter></term>
 <listitem><para>This option rebuilds everything in the
 <filename class="directory">ld</filename> subdirectory. Specifying the LIB_PATH
 makefile variable on the command line allows us to override the default value
diff --git a/chapter05/binutils-pass2.xml b/chapter05/binutils-pass2.xml
index 584fd4513..7eb1cf670 100644
--- a/chapter05/binutils-pass2.xml
+++ b/chapter05/binutils-pass2.xml
@@ -38,9 +38,9 @@ cd ../binutils-build</userinput></screen>
 
 <variablelist>
 <varlistentry>
-<term><userinput>--with-lib-path=/tools/lib</userinput></term>
+<term><parameter>--with-lib-path=/tools/lib</parameter></term>
 <listitem><para>This tells the configure script to specify the library search path 
-during the compilation of Binutils, resulting in <emphasis>/tools/lib</emphasis> 
+during the compilation of Binutils, resulting in <parameter>/tools/lib</parameter>
 to be passed to the linker. This prevents the linker from searching through library 
 directories on the host.</para></listitem>
 </varlistentry>
@@ -63,9 +63,9 @@ will do so:</para>
 <para>Except for a few known failures, the binutils tests should all pass. The
 exceptions to this rule are as follows:</para>
 
-<screen>* 5 FAIL (unexpected failure) for visibility
+<screen><computeroutput>* 5 FAIL (unexpected failure) for visibility
 * 1 FAIL for selective4
-* 1 FAIL for selective5</screen>
+* 1 FAIL for selective5</computeroutput></screen>
 
 <!--
 
@@ -74,7 +74,7 @@ Unfortunately, there is no easy way to view the test results summary like there
 was for the GCC package. However, if a failure occurs here, it should be easy
 to spot. The output shown will contain something like:</para>
 
-<blockquote><screen>make[1]: *** [check-binutils] Error 2</screen></blockquote>
+<blockquote><screen><computeroutput>make[1]: *** [check-binutils] Error 2</computeroutput></screen></blockquote>
 
 -->
 
@@ -82,7 +82,7 @@ to spot. The output shown will contain something like:</para>
 
 <screen><userinput>make install</userinput></screen>
 
-<para>Now prepare the linker for the "Re-adjusting" phase in the next
+<para>Now prepare the linker for the <quote>Re-adjusting</quote> phase in the next
 chapter:</para>
 
 <screen><userinput>make -C ld clean
diff --git a/chapter05/coreutils.xml b/chapter05/coreutils.xml
index f00f4e1ba..efc9e8ba7 100644
--- a/chapter05/coreutils.xml
+++ b/chapter05/coreutils.xml
@@ -31,17 +31,17 @@
 
 <screen><userinput>DEFAULT_POSIX2_VERSION=199209 ./configure --prefix=/tools</userinput></screen>
 
-<para>This package has an issue when compiled against versions of glibc
+<para>This package has an issue when compiled against versions of Glibc
 later than 2.3.2.  Some of the Coreutils utilities (such as
 (<command>head</command>, <command>tail</command> and <command>sort</command>)
 will reject their traditional syntax, a syntax that has been in use for
 approximately 30 years. This old syntax is so pervasive that compatibility
 should be preserved until the many places where it is used can be
 updated.  Backwards compatibility is achieved by setting the
-DEFAULT_POSIX2_VERSION environment variable to &quot;199209&quot; in the above
-command.  If you don&apos;t want coreutils to be backwards compatible
+DEFAULT_POSIX2_VERSION environment variable to <quote>199209</quote> in the above
+command.  If you don't want coreutils to be backwards compatible
 with the traditional syntax, then simply omit setting the DEFAULT_POSIX2_VERSION
-environment variable.  Realise though, that doing so will mean you&apos;ll have
+environment variable.  Realise though, that doing so will mean you'll have
 to deal with the consequences yourself: patch the many packages that still use
 the old syntax.  We therefore recommend using the instructions exactly as given
 above.</para>
@@ -52,7 +52,7 @@ above.</para>
 
 <para>(If you insist on testing the results, then issue:
 <userinput>make RUN_EXPENSIVE_TESTS=yes check</userinput>. The
-<emphasis>RUN_EXPENSIVE_TESTS=yes</emphasis> parameter tells the test suite to
+<parameter>RUN_EXPENSIVE_TESTS=yes</parameter> parameter tells the test suite to
 run several additional tests that are considered relatively expensive on some
 platforms but generally are not a problem on Linux.)</para>
 
diff --git a/chapter05/dejagnu.xml b/chapter05/dejagnu.xml
index 8b156af1c..969eb36db 100644
--- a/chapter05/dejagnu.xml
+++ b/chapter05/dejagnu.xml
@@ -53,7 +53,7 @@ GCC, Glibc, Grep, Make, Sed</seg></seglistitem>
 <listitem>
 <indexterm zone="ch-tools-dejagnu runtest"><primary sortas="b-runtest">runtest</primary></indexterm>
 <para>is the wrapper script that finds the proper
-expect shell and then runs DejaGnu.</para>
+<command>expect</command> shell and then runs DejaGnu.</para>
 </listitem>
 </varlistentry>
 </variablelist>
diff --git a/chapter05/expect.xml b/chapter05/expect.xml
index fa50bd726..274ab0767 100644
--- a/chapter05/expect.xml
+++ b/chapter05/expect.xml
@@ -42,7 +42,7 @@ suite run:</para>
 
 <variablelist>
 <varlistentry>
-<term><userinput>--with-tcl=/tools/lib</userinput></term>
+<term><parameter>--with-tcl=/tools/lib</parameter></term>
 <listitem><para>This ensures that
 the configure script finds the Tcl installation in our temporary tools location.
 We don't want it to find an existing one that may possibly reside on the host
@@ -50,7 +50,7 @@ system.</para></listitem>
 </varlistentry>
 
 <varlistentry>
-<term><userinput>--with-x=no</userinput></term>
+<term><parameter>--with-x=no</parameter></term>
 <listitem><para>This tells the configure
 script not to search for Tk (the Tcl GUI component) or the X Window System
 libraries, both of which may possibly reside on the host system.</para></listitem>
@@ -75,7 +75,7 @@ considered critical.)</para>
 
 <variablelist>
 <varlistentry>
-<term><userinput>SCRIPTS=""</userinput></term>
+<term><parameter>SCRIPTS=""</parameter></term>
 <listitem><para>This prevents installation
 of the supplementary expect scripts which are not needed.</para></listitem>
 </varlistentry>
diff --git a/chapter05/gcc-pass1.xml b/chapter05/gcc-pass1.xml
index 21f71878e..3f43d67bf 100644
--- a/chapter05/gcc-pass1.xml
+++ b/chapter05/gcc-pass1.xml
@@ -31,8 +31,8 @@
 nor the test suite here.</para>
 
 <para>This package is known to behave badly when you change its default
-optimization flags (including the <emphasis>-march</emphasis> and
-<emphasis>-mcpu</emphasis> options). Therefore, if you have defined any
+optimization flags (including the <parameter>-march</parameter> and
+<parameter>-mcpu</parameter> options). Therefore, if you have defined any
 environment variables that override default optimizations, such as CFLAGS and
 CXXFLAGS, we recommend un-setting them when building GCC.</para>
 
@@ -52,27 +52,27 @@ cd ../gcc-build</userinput></screen>
 
 <variablelist>
 <varlistentry>
-<term><userinput>--with-local-prefix=/tools</userinput></term>
-<listitem><para>The purpose of this switch is to remove <filename>/usr/local/include</filename>
+<term><parameter>--with-local-prefix=/tools</parameter></term>
+<listitem><para>The purpose of this switch is to remove <filename class="directory">/usr/local/include</filename>
 from <command>gcc</command>'s include search path. This is not absolutely
 essential; however, we want to try to minimize the influence of the host
 system, so this a sensible thing to do.</para></listitem>
 </varlistentry>
 
 <varlistentry>
-<term><userinput>--enable-shared</userinput></term>
+<term><parameter>--enable-shared</parameter></term>
 <listitem><para>This switch may
 seem counter-intuitive at first. But using it allows the building of
 <filename>libgcc_s.so.1</filename> and <filename>libgcc_eh.a</filename>, and
 having <filename>libgcc_eh.a</filename> available ensures that the configure
 script for Glibc (the next package we compile) produces the proper results.
-Note that the <command>gcc</command> binaries will still be linked
-statically, as this is controlled by the <emphasis>-static</emphasis>
+Note that the GCC binaries will still be linked
+statically, as this is controlled by the <parameter>-static</parameter>
 value of BOOT_LDFLAGS in the next step.</para></listitem>
 </varlistentry>
 
 <varlistentry>
-<term><userinput>--enable-languages=c</userinput></term>
+<term><parameter>--enable-languages=c</parameter></term>
 <listitem><para>This option
 ensures that only the C compiler is built. The option is only needed when you
 have downloaded and unpacked the full GCC tarball.</para></listitem>
@@ -87,12 +87,12 @@ have downloaded and unpacked the full GCC tarball.</para></listitem>
 
 <variablelist>
 <varlistentry>
-<term><userinput>BOOT_LDFLAGS="-static"</userinput></term>
+<term><parameter>BOOT_LDFLAGS="-static"</parameter></term>
 <listitem><para>This tells GCC to link its programs statically.</para></listitem>
 </varlistentry>
 
 <varlistentry>
-<term><userinput>bootstrap</userinput></term>
+<term><parameter>bootstrap</parameter></term>
 <listitem><para>This target doesn't just
 compile GCC, but compiles it several times. It uses the programs compiled in
 a first round to compile itself a second time, and then again a third time.
diff --git a/chapter05/gcc-pass2.xml b/chapter05/gcc-pass2.xml
index a9e08a20b..7b5130376 100644
--- a/chapter05/gcc-pass2.xml
+++ b/chapter05/gcc-pass2.xml
@@ -30,14 +30,14 @@ them against the new Glibc, and test them properly (if running the test suites
 in this chapter). One thing to note, however, is that these test suites are
 highly dependent on properly functioning pseudo terminals (PTYs) which are
 provided by your host. These days, PTYs are most commonly implemented via the
-<emphasis>devpts</emphasis> file system. You can quickly check if your host
+<systemitem class="filesystem">devpts</systemitem> file system. You can quickly check if your host
 system is set up correctly in this regard by performing a simple test:</para>
 
 <screen><userinput>expect -c "spawn ls"</userinput></screen>
 
 <para>The response might be:</para>
 
-<blockquote><screen>The system has no more ptys.  Ask your system administrator to create more.</screen></blockquote>
+<blockquote><screen><computeroutput>The system has no more ptys.  Ask your system administrator to create more.</computeroutput></screen></blockquote>
 
 <para>If you receive the above message, your host doesn't have its PTYs set up
 properly. In this case there is no point in running the test suites for GCC
@@ -48,17 +48,17 @@ working.</para>
 <para>This time we will build both the C and the C++ compilers, so you'll have
 to unpack both the core and the g++ tarballs (and testsuite too, if you want to
 run the tests). Unpacking them in your working directory, they will all unfold
-into a single <filename>gcc-&gcc-version;/</filename> subdirectory.</para>
+into a single <filename class="directory">gcc-&gcc-version;/</filename> subdirectory.</para>
 
 <para>First correct a problem and make an essential adjustment:</para>
 
 <screen><userinput>patch -Np1 -i ../gcc-&gcc-short-version;-no-fixincludes-1.patch
 patch -Np1 -i ../gcc-&gcc-short-version;-specs-1.patch</userinput></screen>
 
-<para>The first patch disables the GCC <quote>fixincludes</quote> script. We
+<para>The first patch disables the GCC <command>fixincludes</command> script. We
 mentioned this 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
+<command>fixincludes</command> 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
 <xref linkend="chapter-building-system"/>, after we've installed the newer
@@ -98,7 +98,7 @@ variables that override the default optimization flags.</para>
 
 <variablelist>
 <varlistentry>
-<term><userinput>--enable-clocale=gnu</userinput></term>
+<term><parameter>--enable-clocale=gnu</parameter></term>
 <listitem><para>This option
 ensures the correct locale model is selected for the C++ libraries under all
 circumstances. If the configure script finds the <emphasis>de_DE</emphasis>
@@ -109,13 +109,13 @@ would run the risk of building ABI incompatible C++ libraries due to the wrong
 </varlistentry>
 
 <varlistentry>
-<term><userinput>--enable-threads=posix</userinput></term>
+<term><parameter>--enable-threads=posix</parameter></term>
 <listitem><para>This enables
 C++ exception handling for multi-threaded code.</para></listitem>
 </varlistentry>
 
 <varlistentry>
-<term><userinput>--enable-__cxa_atexit</userinput></term>
+<term><parameter>--enable-__cxa_atexit</parameter></term>
 <listitem><para>This option
 allows use of __cxa_atexit, rather than atexit, to register C++ destructors for
 local statics and global objects and is essential for fully standards-compliant
@@ -125,13 +125,13 @@ distributions.</para></listitem>
 </varlistentry>
 
 <varlistentry>
-<term><userinput>--enable-languages=c,c++</userinput></term>
+<term><parameter>--enable-languages=c,c++</parameter></term>
 <listitem><para>This option
 ensures that both the C and C++ compilers are built.</para></listitem>
 </varlistentry>
 
 <varlistentry>
-<term><userinput>--disable-libstdcxx-pch</userinput></term>
+<term><parameter>--disable-libstdcxx-pch</parameter></term>
 <listitem><para>Don't build the
 PCH (pre-compiled header) for libstdc++. It takes up a ton of space, and we
 have no use for it.</para></listitem>
@@ -142,7 +142,7 @@ have no use for it.</para></listitem>
 
 <screen><userinput>make</userinput></screen>
 
-<para>There is no need to use the <emphasis>bootstrap</emphasis> target now,
+<para>There is no need to use the <parameter>bootstrap</parameter> target now,
 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>
 
@@ -153,7 +153,7 @@ so:</para>
 
 <screen><userinput>make -k check</userinput></screen>
 
-<para>The <emphasis>-k</emphasis> flag is used to make the test suite run
+<para>The <parameter>-k</parameter> flag is used to make the test suite run
 through to completion and not stop at the first failure. The GCC test suite is
 very comprehensive and is almost guaranteed to generate a few failures. To get
 a summary of the test suite results, run this:</para>
diff --git a/chapter05/gettext.xml b/chapter05/gettext.xml
index 6eb398cf8..b2174d8f8 100644
--- a/chapter05/gettext.xml
+++ b/chapter05/gettext.xml
@@ -36,15 +36,15 @@
 
 <variablelist>
 <varlistentry>
-<term><userinput>--disable-libasprintf</userinput></term>
+<term><parameter>--disable-libasprintf</parameter></term>
 <listitem><para>This flag tells
-Gettext that we don't want its asprintf library.  Nothing in Chapter 5 or 6
-requires this, and gettext gets rebuilt later, so we exclude it to save
+Gettext that we don't want its asprintf library.  Nothing in this chapter or the next
+requires this, and Gettext gets rebuilt later, so we exclude it to save
 time/space.</para></listitem>
 </varlistentry>
 
 <varlistentry>
-<term><userinput>--disable-csharp</userinput></term>
+<term><parameter>--disable-csharp</parameter></term>
 <listitem><para>Gettext has a nasty
 habit of searching for a C# compiler on the host, and building bindings for it.
 We've already <quote>locked</quote> ourselves into the temporary tools though,
diff --git a/chapter05/glibc.xml b/chapter05/glibc.xml
index d32b00034..df76dfa1d 100644
--- a/chapter05/glibc.xml
+++ b/chapter05/glibc.xml
@@ -28,8 +28,8 @@
 <title>Installation of Glibc</title>
 
 <para>This package is known to behave badly when you change its default
-optimization flags (including the <emphasis>-march</emphasis> and
-<emphasis>-mcpu</emphasis> options). Therefore, if you have defined any
+optimization flags (including the <parameter>-march</parameter> and
+<parameter>-mcpu</parameter> options). Therefore, if you have defined any
 environment variables that override default optimizations, such as CFLAGS and
 CXXFLAGS, we recommend un-setting them when building Glibc.</para>
 
@@ -53,40 +53,40 @@ cd ../glibc-build</userinput></screen>
 
 <variablelist>
 <varlistentry>
-<term><userinput>--disable-profile</userinput></term>
+<term><parameter>--disable-profile</parameter></term>
 <listitem><para>This builds the
 libraries without profiling information. Omit this option if you plan to do
 profiling on the temporary tools.</para></listitem>
 </varlistentry>
 
 <varlistentry>
-<term><userinput>--enable-add-ons=nptl</userinput></term>
+<term><parameter>--enable-add-ons=nptl</parameter></term>
 <listitem><para>This tells Glibc to use the NPTL add-on as its threading 
 library.</para></listitem>
 </varlistentry>
 
 <varlistentry>
-<term><userinput>--with-tls</userinput></term>
+<term><parameter>--with-tls</parameter></term>
 <listitem><para>This tells Glibc to include support for TLS (thread-local storage).
 This is required for NPTL to work. </para></listitem>
 </varlistentry>
 
 <varlistentry>
-<term><userinput>--with-binutils=/tools/bin</userinput></term>
+<term><parameter>--with-binutils=/tools/bin</parameter></term>
 <listitem><para>Strictly speaking this switch is not required. But it does ensure 
 nothing can go wrong with regard to what Binutils programs get used during the 
 Glibc build.</para></listitem>
 </varlistentry>
 
 <varlistentry>
-<term><userinput>--without-gd</userinput></term>
+<term><parameter>--without-gd</parameter></term>
 <listitem><para>This prevents the build of the <command>memusagestat</command>
 program, which strangely enough insists on linking against the host's libraries 
 (libgd, libpng, libz, and so forth). </para></listitem>
 </varlistentry>
 
 <varlistentry>
-<term><userinput>--without-cvs</userinput></term>
+<term><parameter>--without-cvs</parameter></term>
 <listitem><para>This is meant to prevent
 the Makefiles from attempting automatic CVS checkouts when using a CVS
 snapshot. But it's not actually needed these days. We use it because it
@@ -95,7 +95,7 @@ suppresses an annoying but harmless warning about a missing
 </varlistentry>
 
 <varlistentry>
-<term><userinput>--with-headers=/tools/glibc-kernheaders</userinput></term>
+<term><parameter>--with-headers=/tools/glibc-kernheaders</parameter></term>
 <listitem><para>This tells Glibc to compile against the <quote>raw</quote> 
 kernel headers, so that it knows exactly what features the kernel has, and can 
 optimize itself accordingly.  Not strictly necessary, but nice to have.</para></listitem>
@@ -104,10 +104,10 @@ optimize itself accordingly.  Not strictly necessary, but nice to have.</para></
 
 <para>During this stage you might see the following warning:</para>
 
-<blockquote><screen>configure: WARNING:
+<blockquote><screen><computeroutput>configure: WARNING:
 *** These auxiliary programs are missing or incompatible versions: msgfmt
 *** some features will be disabled.
-*** Check the INSTALL file for required versions.</screen></blockquote>
+*** Check the INSTALL file for required versions.</computeroutput></screen></blockquote>
 
 <para>The missing or incompatible <command>msgfmt</command> program is
 generally harmless, but it's believed it can sometimes cause problems when
@@ -142,12 +142,12 @@ Certain optimization settings are also known to be a factor here.</para></listit
 host system issues. The exact reasons are not yet clear.</para></listitem>
 
 <listitem><para>The <emphasis>atime</emphasis> test sometimes fails when the
-LFS partition is mounted with the <emphasis>noatime</emphasis> option, or due
+LFS partition is mounted with the <parameter>noatime</parameter> option, or due
 to other file system quirks.</para></listitem>
 
 <listitem><para>The <emphasis>shm</emphasis> test might fail when the host
-system is running the devfs file system but doesn't have the tmpfs file system
-mounted at <filename>/dev/shm</filename> due to lack of support for tmpfs in
+system is running the devfs file system but doesn't have the <systemitem class="filesystem">tmpfs</systemitem> file system
+mounted at <filename class="directory">/dev/shm</filename> due to lack of support for tmpfs in
 the kernel.</para></listitem>
 
 <listitem><para>When running on older and slower hardware, some tests might
diff --git a/chapter05/grep.xml b/chapter05/grep.xml
index 0a357a6eb..92d2c2337 100644
--- a/chapter05/grep.xml
+++ b/chapter05/grep.xml
@@ -36,14 +36,14 @@
 
 <variablelist>
 <varlistentry>
-<term><userinput>--disable-perl-regexp</userinput></term>
+<term><parameter>--disable-perl-regexp</parameter></term>
 <listitem><para>This makes sure that <command>grep</command> does not 
 get linked against a PCRE library that may be present on the host and would not be 
 available once we enter the chroot environment.</para></listitem>
 </varlistentry>
 
 <varlistentry>
-<term><userinput>--with-included-regex</userinput></term>
+<term><parameter>--with-included-regex</parameter></term>
 <listitem><para>This ensures that
 Grep uses its internal regular expression code. Without this switch, Grep will
 use the code from Glibc, which is known to be slightly buggy.</para></listitem>
diff --git a/chapter05/hostreqs.xml b/chapter05/hostreqs.xml
index 9d7853d45..cf90d3e9a 100644
--- a/chapter05/hostreqs.xml
+++ b/chapter05/hostreqs.xml
@@ -10,7 +10,7 @@
 <para>Due to the experimental nature of the current book, the host must be
 running at <emphasis>least</emphasis> a 2.6.2 kernel. The reasons for this high
 requirement is the use of NPTL, but more importantly the use of udev. Udev
-creates devices dynamically by reading from the sysfs file system. Only very
+creates devices dynamically by reading from the <systemitem class="filesystem">sysfs</systemitem> file system. Only very
 recently has support for this file system been implemented in most of the kernel
 drivers, however. We must be sure that all the critical system devices get
 created properly.</para>
diff --git a/chapter05/kernel-headers.xml b/chapter05/kernel-headers.xml
index c7b030b90..d18ac0020 100644
--- a/chapter05/kernel-headers.xml
+++ b/chapter05/kernel-headers.xml
@@ -41,7 +41,7 @@ un-tarring.</para>
 
 <screen><userinput>make include/linux/version.h</userinput></screen>
 
-<para>Create the platform-specific <filename>include/asm</filename>
+<para>Create the platform-specific <filename class="symlink">include/asm</filename>
 symlink:</para>
 
 <screen><userinput>make include/asm</userinput></screen>
diff --git a/chapter05/linux-libc-headers.xml b/chapter05/linux-libc-headers.xml
index 31f1b2b20..a74ce26e3 100644
--- a/chapter05/linux-libc-headers.xml
+++ b/chapter05/linux-libc-headers.xml
@@ -25,7 +25,7 @@
 <title>Installation of Linux-Libc-Headers</title>
 
 <para>For years it has been common practice to use so-called <quote>raw</quote>
-kernel headers (straight from a kernel tarball) in /usr/include, but over the
+kernel headers (straight from a kernel tarball) in <filename class="directory">/usr/include</filename>, but over the
 last few years, the kernel developers have taken a strong stance that such
 things should not be done.  Thus was born the linux-libc-headers project,
 designed to maintain an API stable version of the Linux headers.</para>
diff --git a/chapter05/ncurses.xml b/chapter05/ncurses.xml
index de27b3b3f..9bc86e181 100644
--- a/chapter05/ncurses.xml
+++ b/chapter05/ncurses.xml
@@ -36,7 +36,7 @@
 
 <variablelist>
 <varlistentry>
-<term><userinput>--without-ada</userinput></term>
+<term><parameter>--without-ada</parameter></term>
 <listitem><para>This tells Ncurses not
 to build its Ada bindings, even if an Ada compiler is installed on the host.
 This must be done because once we enter the chroot environment, Ada will no
@@ -44,7 +44,7 @@ longer be available.</para></listitem>
 </varlistentry>
 
 <varlistentry>
-<term><userinput>--enable-overwrite</userinput></term>
+<term><parameter>--enable-overwrite</parameter></term>
 <listitem><para>This tells Ncurses to install its header files into 
 <filename class="directory">/tools/include</filename> instead of 
 <filename class="directory">/tools/include/ncurses</filename> to ensure that 
diff --git a/chapter05/patch.xml b/chapter05/patch.xml
index 8462d3b50..6f7fa5746 100644
--- a/chapter05/patch.xml
+++ b/chapter05/patch.xml
@@ -28,7 +28,7 @@
 <title>Installation of Patch</title>
 
 <para>Prepare Patch for compilation (the preprocessor flag
-<emphasis>-D_GNU_SOURCE</emphasis> is only needed on the PowerPC platform, on
+<parameter>-D_GNU_SOURCE</parameter> is only needed on the PowerPC platform, on
 other architectures you can leave it out):</para>
 
 <screen><userinput>CPPFLAGS=-D_GNU_SOURCE ./configure --prefix=/tools</userinput></screen>
diff --git a/chapter05/perl.xml b/chapter05/perl.xml
index 5038d25bc..c0de05a45 100644
--- a/chapter05/perl.xml
+++ b/chapter05/perl.xml
@@ -40,7 +40,7 @@ right, they are all letters):</para>
 
 <variablelist>
 <varlistentry>
-<term><userinput>-Dstatic_ext='IO Fcntl POSIX'</userinput></term>
+<term><parameter>-Dstatic_ext='IO Fcntl POSIX'</parameter></term>
 <listitem><para>This tells
 Perl to build the minimum set of static extensions needed for installing and
 testing the Coreutils package in the next chapter.</para></listitem>
diff --git a/chapter05/stripping.xml b/chapter05/stripping.xml
index d5fbd8280..935f848e6 100644
--- a/chapter05/stripping.xml
+++ b/chapter05/stripping.xml
@@ -20,7 +20,7 @@ that it doesn't recognize their file format. Most of them are scripts instead
 of binaries.</para>
 
 <para>Take care <emphasis>not</emphasis> to use
-<emphasis>--strip-unneeded</emphasis> on the libraries -- the static ones
+<parameter>--strip-unneeded</parameter> on the libraries -- the static ones
 would be destroyed and you would have to build the three toolchain packages
 all over again.</para>
 
diff --git a/chapter05/tcl.xml b/chapter05/tcl.xml
index 4c2cf7b83..171bbcdc9 100644
--- a/chapter05/tcl.xml
+++ b/chapter05/tcl.xml
@@ -50,7 +50,7 @@ chapter.</para>
 <userinput>TZ=UTC make test</userinput>. However, the Tcl test suite is known
 to experience failures under certain host conditions that are not fully
 understood. Therefore, test suite failures here are not surprising, and are not
-considered critical. The <emphasis>TZ=UTC</emphasis> parameter sets the time
+considered critical. The <parameter>TZ=UTC</parameter> parameter sets the time
 zone to 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
@@ -61,7 +61,7 @@ will be given later on in <xref linkend="chapter-bootscripts"/>.</para>
 <screen><userinput>make install</userinput></screen>
 
 <warning><para><emphasis>Do not remove</emphasis> the
-<filename>tcl&tcl-version;</filename> source directory yet, as the next package
+<filename class="directory">tcl&tcl-version;</filename> source directory yet, as the next package
 will need its internal headers.</para></warning>
 
 <para>Now make a necessary symbolic link:</para>
diff --git a/chapter05/toolchaintechnotes.xml b/chapter05/toolchaintechnotes.xml
index d9ea431d6..666e181e2 100644
--- a/chapter05/toolchaintechnotes.xml
+++ b/chapter05/toolchaintechnotes.xml
@@ -27,19 +27,19 @@ words, more advanced techniques could be used to build the system.</para>
 platform, often also referred to as the <emphasis>target triplet</emphasis>. For
 many folks the target triplet will probably be
 <emphasis>i686-pc-linux-gnu</emphasis>. A simple way to determine your target
-triplet is to run the <filename>config.guess</filename> script that comes with
+triplet is to run the <command>config.guess</command> script that comes with
 the source for many packages. Unpack the Binutils sources and run the script:
 <userinput>./config.guess</userinput> and note the output.</para>
 
 <para>You'll also need to be aware of the name of your platform's
 <emphasis>dynamic linker</emphasis>, often also referred to as the
 <emphasis>dynamic loader</emphasis>, not to be confused with the standard linker
-<emphasis>ld</emphasis> that is part of Binutils. The dynamic linker is provided
+<command>ld</command> that is part of Binutils. The dynamic linker is provided
 by Glibc and has the job of finding and loading the shared libraries needed by a
 program, preparing the program to run and then running it. For most folks the
-name of the dynamic linker will be <emphasis>ld-linux.so.2</emphasis>. On
+name of the dynamic linker will be <filename>ld-linux.so.2</filename>. On
 platforms that are less prevalent, the name might be
-<emphasis>ld.so.1</emphasis> and newer 64 bit platforms might even have
+<filename>ld.so.1</filename> and newer 64 bit platforms might even have
 something completely different. You should be able to determine the name
 of your platform's dynamic linker by looking in the
 <filename class="directory">/lib</filename> directory on your host system. A
@@ -63,7 +63,7 @@ path to ensure programs are linked only against libraries we
 choose.</para></listitem>
 
 <listitem><para>Careful manipulation of <command>gcc</command>'s
-<emphasis>specs</emphasis> file to tell the compiler which target dynamic
+<filename>specs</filename> file to tell the compiler which target dynamic
 linker will be used.</para></listitem>
 </itemizedlist>
 
@@ -81,29 +81,29 @@ much time is wasted.</para>
 <filename class="directory">/tools/$TARGET_TRIPLET/bin</filename>. In reality,
 the tools in one location are hard linked to the other. An important facet of
 the linker is its library search order. Detailed information can be obtained
-from <command>ld</command> by passing it the <emphasis>--verbose</emphasis>
+from <command>ld</command> by passing it the <parameter>--verbose</parameter>
 flag. For example: <command>ld --verbose | grep SEARCH</command> will
 show you the current search paths and their order. You can see what files are
 actually linked by <command>ld</command> by compiling a dummy program and
-passing the <emphasis>--verbose</emphasis> switch to the linker. For example:
-<command>gcc dummy.c -Wl,--verbose 2&gt;&amp;1 | grep succeeded</command>
+passing the <parameter>--verbose</parameter> switch to the linker. For example:
+<userinput>gcc dummy.c -Wl,--verbose 2&gt;&amp;1 | grep succeeded</userinput>
 will show you all the files successfully opened during the linking.</para>
 
 <para>The next package installed is GCC and during its run of
 <command>./configure</command> you'll see, for example:</para>
 
-<blockquote><screen>checking what assembler to use... /tools/i686-pc-linux-gnu/bin/as
-checking what linker to use... /tools/i686-pc-linux-gnu/bin/ld</screen></blockquote>
+<blockquote><screen><computeroutput>checking what assembler to use... /tools/i686-pc-linux-gnu/bin/as
+checking what linker to use... /tools/i686-pc-linux-gnu/bin/ld</computeroutput></screen></blockquote>
 
 <para>This is important for the reasons mentioned above. It also demonstrates
 that GCC's configure script does not search the PATH directories to find which
 tools to use. However, during the actual operation of <command>gcc</command>
 itself, the same search paths are not necessarily used. You can find out which
 standard linker <command>gcc</command> will use by running:
-<command>gcc -print-prog-name=ld</command>.
+<userinput>gcc -print-prog-name=ld</userinput>.
 Detailed information can be obtained from <command>gcc</command> by passing
-it the <emphasis>-v</emphasis> flag while compiling a dummy program. For
-example: <command>gcc -v dummy.c</command> will show you detailed
+it the <parameter>-v</parameter> flag while compiling a dummy program. For
+example: <userinput>gcc -v dummy.c</userinput> will show you detailed
 information about the preprocessor, compilation and assembly stages, including
 <command>gcc</command>'s include search paths and their order.</para>
  
@@ -117,15 +117,15 @@ switches to enforce the correct selections. After the run of
 <filename>config.make</filename> file in the
 <filename class="directory">glibc-build</filename> directory for all the
 important details. You'll note some interesting items like the use of
-<emphasis>CC="gcc -B/tools/bin/"</emphasis> to control which binary tools are
-used, and also the use of the <emphasis>-nostdinc</emphasis> and
-<emphasis>-isystem</emphasis> flags to control the compiler's include search
+<parameter>CC="gcc -B/tools/bin/"</parameter> to control which binary tools are
+used, and also the use of the <parameter>-nostdinc</parameter> and
+<parameter>-isystem</parameter> flags to control the compiler's include search
 path. These items help to highlight an important aspect of the Glibc package:
 it is very self-sufficient in terms of its build machinery and generally does
 not rely on toolchain defaults.</para>
 
 <para>After the Glibc installation, we make some adjustments to ensure that
-searching and linking take place only within our <filename>/tools</filename>
+searching and linking take place only within our <filename class="directory">/tools</filename>
 prefix. We install an adjusted <command>ld</command>, which has a hard-wired
 search path limited to <filename class="directory">/tools/lib</filename>. Then
 we amend <command>gcc</command>'s specs file to point to our new dynamic
@@ -133,7 +133,7 @@ linker in <filename class="directory">/tools/lib</filename>. This last step is
 <emphasis>vital</emphasis> to the whole process. As mentioned above, a
 hard-wired path to a dynamic linker is embedded into every ELF shared
 executable. You can inspect this by running:
-<command>readelf -l &lt;name of binary&gt; | grep interpreter</command>.
+<userinput>readelf -l &lt;name of binary&gt; | grep interpreter</userinput>.
 By amending <command>gcc</command>'s specs file, we are ensuring that every
 program compiled from here through the end of this chapter will use our new
 dynamic linker in <filename class="directory">/tools/lib</filename>.</para>
@@ -145,7 +145,7 @@ programs themselves having the name of the dynamic linker from the host system's
 would defeat our goal of getting away from the host.</para>
 
 <para>During the second pass of Binutils, we are able to utilize the
-<emphasis>--with-lib-path</emphasis> configure switch to control
+<parameter>--with-lib-path</parameter> configure switch to control
 <command>ld</command>'s library search path. From this point onwards, the
 core toolchain is self-contained and self-hosted. The remainder of the
 <xref linkend="chapter-temporary-tools"/> packages all build against the new Glibc in
diff --git a/chapter05/udev.xml b/chapter05/udev.xml
index 9df6d5bde..5b38a2baf 100644
--- a/chapter05/udev.xml
+++ b/chapter05/udev.xml
@@ -36,8 +36,7 @@ being owned by user root, group root, and only accessible to root. As you
 can easily imagine, this isn't ideal. Give it a much better configuration
 by applying the following patch:</para>
 
-<screen><userinput>patch -Np1 -i ../udev-&udev-version;-config-2.patch
-</userinput></screen>
+<screen><userinput>patch -Np1 -i ../udev-&udev-version;-config-2.patch</userinput></screen>
 
 <para>The udevstart program hardcodes the path to the udev program in itself,
 which is bad since we install udev in a non-standard location. Fix this by
diff --git a/chapter05/util-linux.xml b/chapter05/util-linux.xml
index a04ca972e..2828dc629 100644
--- a/chapter05/util-linux.xml
+++ b/chapter05/util-linux.xml
@@ -33,7 +33,7 @@ by applying the following patch:</para>
 <screen><userinput>patch -Np1 -i ../util-linux-&util-linux-version;-kernel-headers-1.patch</userinput></screen>
 
 <para>Util-linux doesn't use the freshly installed headers and libraries
-from the /tools directory.  This is fixed by altering the configure
+from the <filename class="directory">/tools</filename> directory.  This is fixed by altering the configure
 script:</para>
 
 <screen><userinput>sed -i "s@/usr/include@/tools/include@g" configure</userinput></screen>