Small text rearrangement.

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

1 files changed, 11 insertions, 14 deletions

diff --git a/chapter01/how.xml b/chapter01/how.xml
index 79d1bc869..12e8d781b 100644
--- a/chapter01/how.xml
+++ b/chapter01/how.xml
@@ -16,7 +16,7 @@ partition and filesystem is where your new LFS system will be compiled and
 installed onto.</para>
 
 <para>Chapter 5 will then discuss the installation of a number of packages that 
-will form the basic development suite (or tool-set) which is used to build the 
+will form the basic development suite (or toolset) 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>
@@ -31,7 +31,7 @@ pass.</para>
 <para>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, 
+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. This is known as <quote>self 
 contained</quote> and <quote>self hosted</quote>. There is a discussion of the 
@@ -45,19 +45,16 @@ is to ensure that as little information from your host makes it into your new
 pristine LFS system. When you build the first two packages in Chapter 5, 
 Binutils and GCC, they will be compiled statically.  This means that the 
 version of the C library on your host distribution will be embedded inside all 
-the binary programs you just compiled. This will cause problems for you down 
-the road (they have been well documented). The host's Glibc is usually an 
-unknown quantity and can contain bugs or anything else we don't know about 
+the binary programs you just compiled. This has the potential to cause
+problems for you down the road. The host's Glibc is usually an unknown
+quantity and might even contain bugs or anything else we don't know about 
 until it is too late. A well known issue is that statically linked binaries 
-compiled on a Glibc-2.2.x based system that then contain calls to the 
-<emphasis>getpwuid()</emphasis> function crash when run on a Glibc-2.3.x based
-system.  You are 
-about to build a Glibc-2.3.x based system.  You do not want to build something 
-that is going to crash do you?  Finally, the Glibc autoconf tests produce 
-different results depending on whether an existing Glibc is found on the host 
-distribution. This can lead to inconsistencies and encourages hacks and 
-workarounds. With all these things in mind, you can see that the extra effort 
-to compile Binutils and GCC twice is well worth it.</para>
+compiled on a Glibc-2.2.x based system that contain calls to the getpwuid()
+function crash when run on a glibc-2.3.x based system. Seeing as we are about
+to build a Glibc-2.3.x based system, we need to shield ourselves from problems
+of this nature. The procedure employed in Chapter 5 achieves this goal. With
+all these things in mind, you can see that the extra effort to compile
+Binutils and GCC twice is well worth it.</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