From c3dc67cdcf7eebbffd7d69de741251a0c08443a1 Mon Sep 17 00:00:00 2001
From: Alex Gronenwoud <alex@linuxfromscratch.org>
Date: Sat, 14 Feb 2004 14:53:12 +0000
Subject: Changing a few SBUs.

git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@3251 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
---
 chapter05/chapter05.xml | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

(limited to 'chapter05/chapter05.xml')

diff --git a/chapter05/chapter05.xml b/chapter05/chapter05.xml
index 870c02ba6..aa00353a2 100644
--- a/chapter05/chapter05.xml
+++ b/chapter05/chapter05.xml
@@ -155,7 +155,7 @@ will show you all the files successfully opened during the linking.</para>
 checking what linker to use... /tools/i686-pc-linux-gnu/bin/ld</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
+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:
@@ -169,7 +169,7 @@ information about the preprocessor, compilation and assembly stages, including
 <para>The next package installed is Glibc. The most important considerations for
 building Glibc are the compiler, binary tools and kernel headers. The compiler
 is generally no problem as Glibc will always use the <command>gcc</command>
-found in a $PATH directory. The binary tools and kernel headers can be a little
+found in a PATH directory. The binary tools and kernel headers can be a little
 more troublesome. Therefore we take no risks and use the available configure
 switches to enforce the correct selections. After the run of
 <command>./configure</command> you can check the contents of the
@@ -525,10 +525,10 @@ problem is and correct it. There is no point in continuing until this is done.
 First, redo the sanity check using <command>gcc</command> instead of
 <command>cc</command>. If this works it means the
 <filename class="symlink">/tools/bin/cc</filename> symlink is missing. Revisit
-<xref linkend="ch-tools-gcc-pass1"/> and fix the symlink. Second, ensure your $PATH
+<xref linkend="ch-tools-gcc-pass1"/> and fix the symlink. Second, ensure your PATH
 is correct. You can check this by running <userinput>echo $PATH</userinput> and
 verifying that <filename class="directory">/tools/bin</filename> is at the head
-of the list. If the $PATH is wrong it could mean you're not logged in as user
+of the list. If the PATH is wrong it could mean you're not logged in as user
 <emphasis>lfs</emphasis> or something went wrong back in
 <xref linkend="ch-tools-settingenviron"/>. Third, something may have gone wrong with
 the specs file amendment above. In this case redo the specs file amendment
@@ -586,8 +586,9 @@ 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 -- they would be
-destroyed and you would have to build Glibc all over again.</para>
+<emphasis>--strip-unneeded</emphasis> on the libraries -- the static ones
+would be destroyed and you would have to build the three toolchain packages
+all over again.</para>
 
 <para>To save another couple of megabytes, you can throw away all the
 documentation:</para>
-- 
cgit v1.2.3-54-g00ecf