Applied Alex' "apapting-the-text.patch" patch

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

chapter05/adding-user.xml

@@ -2,24 +2,26 @@
 <title>Adding the user lfs</title>
 <?dbhtml filename="addinguser.html" dir="chapter05"?>
 
-<para>If you are logged in as <emphasis>root</emphasis> during Chapter 5,
-your host system can be damaged by a single mistake. We recommend that
-you build the packages in Chapter 5 as an unprivileged user. You could use
-your own user name, but to ensure a clean build environment, we'll create a
-new user: <emphasis>lfs</emphasis>. As <emphasis>root</emphasis>, issue
-the following commands to add the new user:</para>
+<para>When logged in as <emphasis>root</emphasis>, making a single mistake
+can damage or even wreck your system. Therefore we recommend that you
+build the packages in this chapter as an unprivileged user. You could
+of course use your own user name,  but to make it easier to set up a clean
+work environment we'll create a new user <emphasis>lfs</emphasis> and
+use this one during the installation process. As <emphasis>root</emphasis>,
+issue the following commands to add the new user:</para>
 
 <para><screen><userinput>useradd -s /bin/bash -m lfs
 passwd lfs</userinput></screen></para>
 
-<para>In order to grant ownership of the <filename>$LFS/stage1</filename>
-directory to the user <emphasis>lfs</emphasis>, issue the command:</para>
+<para>Now grant this new user <emphasis>lfs</emphasis> full access to
+<filename class="directory">$LFS/stage1</filename> by giving it ownership
+of the directory:</para>
 
 <para><screen><userinput>chown lfs $LFS/stage1</userinput></screen></para>
 
-<para>Next, login as user <emphasis>lfs</emphasis>. This can be accomplished
-via a virtual console, display manager or with the substitute user
-command:</para>
+<para>Next, login as user <emphasis>lfs</emphasis>. This can be done via a
+virtual console, through a display manager, or with the following substitute
+user command:</para>
 
 <para><screen><userinput>su - lfs</userinput></screen></para>
 

chapter05/binutils-pass1-inst.xml

@@ -3,11 +3,15 @@
 <sect2>
 <title>Installation of Binutils</title>
 
+<para>It is important that Binutils be the first package to get compiled,
+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 have changed its default
 optimization flags (including the -march and -mcpu options). Therefore, if
 you have defined any environment variables that override default
 optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting or
-modifying them when building binutils.</para>
+modifying them when building Binutils.</para>
 
 <para>It is recommended by the Binutils installation documentation to build
 Binutils outside of the source directory in a dedicated directory:</para>
@@ -20,13 +24,16 @@ cd ../binutils-build</userinput></screen></para>
 <para><screen><userinput>../binutils-&binutils-version;/configure \
 &nbsp;&nbsp;&nbsp;&nbsp;--prefix=/stage1 --disable-nls</userinput></screen></para>
 
-<para>The meaning of the (new) configure switches are:</para>
+<para>The meaning of the configure switches is:</para>
 
 <itemizedlist>
-<listitem><para><userinput>--disable-nls</userinput>: This option disables
-internationalization (also known as i18n). We don't need this for our
-static programs and nls often causes problems when you're linking
-statically.</para></listitem>
+<listitem><para><userinput>--prefix=/stage1</userinput>: This tells the
+configure script to prepare to install the Binutils programs in the
+<filename>/stage1</filename> directory.</para></listitem>
+<listitem><para><userinput>--disable-nls</userinput>: 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>
 </itemizedlist>
 
 <para>Continue with compiling the package:</para>
@@ -36,24 +43,23 @@ statically.</para></listitem>
 <para>The meaning of the make option is:</para>
 
 <itemizedlist>
-<listitem><para><userinput>LDFLAGS="-all-static"</userinput>: This is
-how we tell Binutils that all programs should be statically linked. Setting
-the <emphasis>LDFLAGS</emphasis> variable is the common way of specifying we
-want a static link to take place, however, its value and the way it is set
-is not always the same. You'll see with the remaining packages that there
-are different ways of setting up the <emphasis>LDFLAGS</emphasis>
-variable.</para></listitem>
+<listitem><para><userinput>LDFLAGS="-all-static"</userinput>: This tells
+the linker that all the Binutils programs should be linked
+statically.</para></listitem>
 </itemizedlist>
 
-<para>And finish off installing the package:</para>
+<para>And install the package:</para>
 
 <para><screen><userinput>make install</userinput></screen></para>
 
+<para>Now already prepare the linker for the "locking in" of
+<emphasis>glibc</emphasis> later on:</para>
+
 <para><screen><userinput>make -C ld clean
 make -C ld LIB_PATH=/stage1/lib</userinput></screen></para>
 
-<para>Do not remove the binutils-* directories. We need them again
-later on in this chapter.</para>
+<para><emphasis>Do not yet remove</emphasis> the binutils-* directories.
+We will need them again a bit further on in this chapter.</para>
 
 </sect2>
 

chapter05/creatingstage1dir.xml

@@ -11,15 +11,17 @@ required directory by running the following:</para>
 
 <para><screen><userinput>mkdir $LFS/stage1</userinput></screen></para>
 
-<para>The next step is to create a "/stage1" symlink on the host system. It
-will point to the directory we just created on the LFS partition:</para>
+<para>The next step is to create a <filename>/stage1</filename> symlink on
+your host system. It will point to the directory we just created on the LFS
+partition:</para>
 
 <para><screen><userinput>ln -s $LFS/stage1 /</userinput></screen></para>
 
-<para>This ensures our toolchain will look in the same place (i.e. /stage1)
-in both Chapters 5 and 6 (when we are inside the chroot). This is an
-important concept to grasp. Don't worry if it's not clear right now, all
-will make sense once we get into Chapter 6.</para>
+<para>This symlink enables us to compile our toolchain so that it always
+refers to <filename>/stage1</filename>, meaning that the compiler, assembler
+and linker will work both in this chapter (when we are still rummaging around
+on the host) <emphasis>and</emphasis> in the next (when we are chrooted to
+the LFS partition).</para>
 
 </sect1>
 

chapter05/gcc-pass1-inst.xml

@@ -3,7 +3,7 @@
 <sect2>
 <title>Installation of GCC</title>
 
-<para>We won't be needing a C++ compiler until Chapter 6. So, only
+<para>We won't be needing a C++ compiler until the next chapter. So, only
 the gcc-core tarball needs to be unpacked at this time.</para>
 
 <para>This package is known to behave badly when you have changed its
@@ -28,79 +28,58 @@ cd ../gcc-build</userinput></screen></para>
 &nbsp;&nbsp;&nbsp;&nbsp;--disable-nls --enable-shared \
 &nbsp;&nbsp;&nbsp;&nbsp;--enable-languages=c</userinput></screen></para>
 
-<para>The meaning of the configure options are:</para>
+<para>The meaning of the new configure options is:</para>
 
 <itemizedlist>
-<listitem><para><userinput>--prefix=/static</userinput>: This is NOT a
-typo. GCC hard codes some paths while compiling and so we need to pass
-<filename class="directory">/static</filename> as the prefix during the
-configure stage. We will pass the real installation prefix (<filename
-class="directory">$LFS/static</filename>) during the installation
-stage later on.</para></listitem>
-
-<listitem><para><userinput>--disable-shared</userinput>: This prevents the
-build of dynamic libraries. They are useless to us at the moment. We'll
-create them when we reinstall GCC in chapter 6.</para></listitem>
-
-<listitem><para><userinput>--with-as=$LFS/static/bin/as and
---with-ld=$LFS/static/bin/ld</userinput>: GCC can be miscompiled if your
-host distribution's Binutils package is quite old. We need a good working
-static GCC until we reinstall GCC later in chapter 6. So by using
-<filename>as</filename> and <filename>ld</filename> from the Binutils
-package we compiled earlier in this chapter we ensure that GCC will work
-correctly.</para></listitem>
+<listitem><para><userinput>--with-local-prefix=/stage1</userinput>:  The
+purpose of this switch is to remove <filename>/usr/local/include</filename>
+from <userinput>gcc</userinput>'s include search path. This is not absolutely
+essential, but we want to try and minimize the influence from the host system,
+so this seems a logical thing to do.</para></listitem>
+
+<listitem><para><userinput>--enable-shared</userinput>: 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.
+Please note that the <userinput>gcc</userinput> binaries will still be linked
+statically, as this is controlled by the <userinput>-static</userinput>
+value of BOOT_LDFLAGS further on.</para></listitem>
+
+<listitem><para><userinput>--enable-languages=c</userinput>: This will build
+only the C compiler from the GCC package. We won't be needing anything else
+during this chapter.</para></listitem>
 </itemizedlist>
 
 <para>Continue with compiling the package:</para>
 
 <para><screen><userinput>make BOOT_LDFLAGS="-static" bootstrap</userinput></screen></para>
 
-<para>The meaning of the make options are:</para>
+<para>The meaning of the make parameters is:</para>
 
 <itemizedlist>
-<listitem><para><userinput>BOOT_LDFLAGS="-static"</userinput>: This is
-GCC's equivalent to make LDFLAGS="-static" as we use with other packages to
-compile them statically.</para></listitem>
-
-<listitem><para><userinput>bootstrap</userinput>: The
-<emphasis>bootstrap</emphasis> target doesn't just compile GCC, but it
-compiles GCC a second time. It uses the first compiled programs to compile
-itself a second and third time to make sure the compiler was compiled properly
-and can compile itself properly.</para></listitem>
+<listitem><para><userinput>BOOT_LDFLAGS="-static"</userinput>: This tells
+GCC to link its programs statically.</para></listitem>
+
+<listitem><para><userinput>bootstrap</userinput>: 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.
+It then compares these second and third compiles to make sure it can
+reproduce itself flawlessly, which most probably means that it was
+compiled correctly.</para></listitem>
 </itemizedlist>
 
-<para>And finish off installing the package:</para>
+<para>And install the package:</para>
 
 <para><screen><userinput>make install</userinput></screen></para>
 
-<para>The meaning of the make option is:</para>
-
-<itemizedlist>
-<listitem><para><userinput>install-no-fixedincludes</userinput>: This prevents
-the fixincludes script from running. Preventing this is necessary because
-under normal circumstances the GCC installation will run the fixincludes
-script which scans your system for header files that need to be fixed. It
-might find that the Glibc header files of your host system need to be fixed.
-If so, it will fix them and put them in
-<filename>$LFS/static/lib/gcc-lib/i686-pc-linux-gnu/3.2</filename>. Later on
-in chapter 6 you will install Glibc which will put its header files in
-<filename>/usr/include</filename>. Next you will install other programs that
-use the Glibc headers and GCC will look in
-<filename>/static/lib/gcc-lib</filename> before looking in
-<filename>/usr/include</filename>, with the result of finding and using the
-fixed Glibc header files from your host distribution, which are probably
-incompatible with the Glibc version actually used on the LFS
-system.</para></listitem>
-</itemizedlist>
-
-<para>As the finishing touch we'll create the <filename
-class="symlink">$LFS/static/bin/cc</filename> symlink. A lot of programs
-and scripts try to run <userinput>cc</userinput> instead of
-<userinput>gcc</userinput> This is to keep programs generic and usable on
-all kinds of Unix systems. Not everybody has GNU CC installed. Just running
-<userinput>cc</userinput> (C Compiler) leaves the user free to decide which
-C compiler to install. The symlink will point to the system's default
-compiler.</para>
+<para>As a finishing touch we'll create the <filename
+class="symlink">/stage1/bin/cc</filename> symlink. Many programs and
+scripts run <userinput>cc</userinput> instead of <userinput>gcc</userinput>,
+a thing meant to keep programs generic and therefore usable on all kinds of
+Unix systems. Not everybody has the GNU C compiler installed. Simply running
+<userinput>cc</userinput> leaves the system administrator free to decide what
+C compiler to install, as long as there's a symlink pointing to it:</para>
 
 <para><screen><userinput>ln -sf gcc /stage1/bin/cc</userinput></screen></para>
 

chapter05/glibc-inst.xml

@@ -15,11 +15,11 @@ default optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting
 them when building Glibc.</para>
 
 <para>Basically, compiling Glibc in any other way than the book suggests
-is putting your system at a very high risk.</para>
+is putting the stability of your system at risk.</para>
 
 <para>Though it is a harmless message, the install stage of Glibc will
-complain about the presence of /etc/ld.so.conf (or lack thereof). Fix
-this annoying little error:</para>
+complain about the absence of <filename>/etc/ld.so.conf</filename>.
+Fix this annoying little error with:</para>
 
 <para><screen><userinput>mkdir /stage1/etc
 touch /stage1/etc/ld.so.conf</userinput></screen></para>
@@ -38,7 +38,7 @@ cd ../glibc-build</userinput></screen></para>
 &nbsp;&nbsp;&nbsp;&nbsp;--with-binutils=/stage1/bin \
 &nbsp;&nbsp;&nbsp;&nbsp;--without-gd</userinput></screen></para>
 
-<para>The meaning of the configure options are:</para>
+<para>The meaning of the new configure options is:</para>
 
 <itemizedlist>
 <listitem><para><userinput>--disable-profile</userinput>: This disables the
@@ -46,11 +46,18 @@ building of the libraries with profiling information. Omit this option if you
 plan to do profiling.</para></listitem>
 
 <listitem><para><userinput>--enable-add-ons</userinput>: This enables any
-add-ons that we installed with Glibc, in our case Linuxthreads.</para></listitem>
-
-<listitem><para><userinput>--libexecdir=/usr/bin</userinput>: This will
-cause the <filename>pt_chown</filename> program to be installed in the
-<filename>/usr/bin</filename> directory.</para></listitem>
+add-ons that were installed with Glibc, in our case Linuxthreads.</para></listitem>
+
+<listitem><para><userinput>--with-binutils=/stage1/bin</userinput> and
+<userinput>--with-headers=/stage1/include</userinput>: Strictly speaking
+these switches are not required. But they ensure nothing can go wrong with
+regard to what kernel headers and Binutils programs get used during the
+Glibc build.</para></listitem>
+
+<listitem><para><userinput> --without-gd</userinput>: This switch ensures
+that we don't build the <userinput>memusagestat</userinput> program, which
+strangely enough insists on linking against the host's libraries (libgd,
+libpng, libz, and so forth).</para></listitem>
 </itemizedlist>
 
 <para>During this stage you will see the following warning:</para>
@@ -76,16 +83,17 @@ would require you to regenerate the binary files.</para>
 make check
 make install</userinput></screen></para>
 
-<para>The locales (used by Glibc to make your Linux system talk in a different
-language) weren't installed when you ran the previous command, so we have to
-do that ourselves now:</para>
+<para>The locales (used by Glibc to make your Linux system respond in a
+different language) weren't installed when you ran the previous command,
+so we have to do that ourselves now:</para>
 
 <para><screen><userinput>make localedata/install-locales</userinput></screen></para>
 
-<para>An alternative to running the previous command is to install only those
-locales which you need or want. This can be achieved using the localedef
-command. Information on this can be found in the <filename>INSTALL</filename>
-file in the <filename>glibc-&glibc-version;</filename> tree.</para>
+<para>An alternative to running the previous command is to install only
+those locales which you need or want. This can be achieved by using the
+<userinput>localedef</userinput> command. Information on this can be
+found in the <filename>INSTALL</filename> file in the
+<filename>glibc-&glibc-version;</filename> tree.</para>
 
 </sect2>
 

chapter05/introduction.xml

@@ -6,16 +6,23 @@
 Linux system. This system will contain just enough tools to be able
 to start constructing the final LFS system in the next chapter.</para>
 
+<para>The building of this minimal system is done in two steps: first we
+build a brand-new and host-independent toolchain (compiler, assembler,
+linker and libraries), and then use this to build all the other essential
+tools.</para>
+
 <para>The files compiled in this chapter will be installed under the
-<filename class="directory">$LFS/static</filename> directory,
+<filename class="directory">$LFS/stage1</filename> directory,
 to keep them separate from the files installed in the next chapter.
 Since the packages compiled here are merely temporary, we don't want
 them to pollute the soon-to-be LFS system.</para>
 
 <para>The key to learning what makes a Linux system work is to know
-exactly what each package is used for, and why the user or the system
-needs it. For this purpose a short description of the content of each
-package is given right after the installation instructions.</para>
+what each package is used for, why the user or the system needs it.
+For this purpose a short summary of the content of each package is given
+before the actual installation instructions. For a short description of
+each program in a package, please refer to the corresponding section in
+<xref linkend="appendixa"/>.</para>
 
 <para>Several of the packages are patched before compilation, but only when
 the patch is needed to circumvent a problem. Often the patch is needed in

chapter05/kernelheaders-inst.xml

@@ -3,27 +3,11 @@
 <sect2>
 <title>Installation of the kernel headers</title>
 
-<para>We won't be compiling a new kernel yet -- we'll do that when we have
-finished the installation of all the packages. But as some packages need the
-kernel header files, we're going to unpack the kernel archive now, set it up
-and copy the header files so they can be found by these packages.</para>
-
-<para>It is important to note that the files in the kernel source directory
-are not owned by <emphasis>root</emphasis>. Whenever you unpack a package as
-user <emphasis>root</emphasis> (like we do here inside chroot), the files end
-up having the user and group IDs of whatever they were on the packager's
-computer. This is usually not a
-problem for any other package you install because you remove the source
-tree after the installation. But the Linux kernel source tree is often kept
-around for a long time, so there's a chance that whatever user ID the packager
-used will be assigned to somebody on your machine and then that person would
-have write access to the kernel source.</para>
-
-<para>In light of this, you might want to run <userinput>chown -R 0:0</userinput>
-on the <filename>linux-&kernel-version;</filename> directory
-to ensure all files are owned by user <emphasis>root</emphasis>.</para>
-
-<para>Prepare for header installation:</para>
+<para>As some packages need to refer to the kernel header files, we're going
+to unpack the kernel archive now, set it up, and copy the required files to a
+place where <userinput>gcc</userinput> can later find them.</para>
+
+<para>Prepare for the header installation with:</para>
 
 <para><screen><userinput>make mrproper</userinput></screen></para>
 
@@ -41,7 +25,7 @@ symlink:</para>
 
 <para><screen><userinput>make symlinks</userinput></screen></para>
 
-<para>Install the platform specific-header files:</para>
+<para>Install the platform-specific header files:</para>
 
 <para><screen><userinput>mkdir /stage1/include/asm
 cp include/asm/* /stage1/include/asm

chapter05/lockingglibc.xml

@@ -5,12 +5,27 @@
 <sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
 
 <sect2>
-<title>Installation of Binutils</title>
+<title>Installation of the linker scripts</title>
 
 <para><screen><userinput>make -C ld install-data-local</userinput></screen></para>
 
-<para>You can remove the binutils-* directories now.</para>
+<para>This installs the adjusted linker scripts. Remember they were adjusted
+a little while back, at the end of the first pass of Binutils? The linker
+scripts now contain no mention of <filename>/lib</filename>,
+<filename>/usr/lib</filename> or <filename>/usr/local/lib</filename>.
+From this point onwards everything will link <emphasis>only</emphasis>
+against the libraries in <filename>/stage1/lib</filename>.</para>
 
+<para>You can now remove the binutils-* directories.</para>
+
+</sect2>
+
+<sect2>
+<title>Amending GCC's specs file</title>
+
+<para>The final thing to do is to amend our GCC specs file so that it points
+to the new dynamic linker. A simple sed will accomplish this:</para>
+   
 <para><screen><userinput>SPECFILE=/stage1/lib/gcc-lib/*/*/specs
 sed -e 's@/lib/ld.so.1@/stage1/lib/ld.so.1@g' \
 &nbsp;&nbsp;&nbsp;&nbsp;-e 's@/lib/ld-linux.so.2@/stage1/lib/ld-linux.so.2@g' \
@@ -18,6 +33,13 @@ sed -e 's@/lib/ld.so.1@/stage1/lib/ld.so.1@g' \
 mv XX $SPECFILE
 unset SPECFILE</userinput></screen></para>
 
+<para>We recommend that you cut-and-paste the above rather than try and type
+it all in. Or you can edit the specs file by hand if you want to: just replace
+"/lib/ld-linux.so.2" with "/stage1/lib/ld-linux.so.2".</para>
+
+<para>This completes the installation of the self-contained toolchain, which
+can now be used to build the rest of the temporary tools.</para>
+
 </sect2>
 
 </sect1>

chapter05/setting-environment.xml

@@ -1,6 +1,6 @@
 <sect1 id="ch05-settingenviron">
 <title>Setting up the environment</title>
-<?dbhtml filename="settingenviron.html" dir="chapter05"?>
+<?dbhtml filename="settingenvironment.html" dir="chapter05"?>
 
 <para>While logged in as user <emphasis>lfs</emphasis>, issue the
 following commands to set up a good work environment:</para>
@@ -13,41 +13,41 @@ LC_ALL=POSIX
 PATH=/stage1/bin:$PATH
 export LFS LC_ALL PATH
 EOF
-source ~/.bash_profile</userinput></screen></para>
 
-<para><userinput>set +h</userinput> turns off Bash's hash function. Hash
-normally is a useful feature where Bash uses a hash table to remember the
-full pathnames of executable files to avoid multiple `PATH' searches.
-However, we'd like the new tools to become available as soon as they are
-installed.  By switching off the hash function, our "interactive" commands
-(make, patch, sed, cp and so forth) will always use the newest available
-during the build process.</para>
-
-<para>This profile sets the umask to 022, so newly created files and
-directories will have the correct permissions. To be more specific, only
-the file owner will have write permission to new files and directories.
-Other users of the system will be have read permission, and executable
-permission to directories. It is advisable to keep this setting throughout
-your LFS installation.</para>
+source ~/.bash_profile</userinput></screen></para>
 
+<para>The <userinput>set +h</userinput> command turns off
+<userinput>bash</userinput>'s hash function. Normally hashing is a useful
+feature: <userinput>bash</userinput> uses a hash table to remember the
+full pathnames of executable files to avoid searching the PATH time and time
+again to find the same executable. However, we'd like the new tools to be
+used as soon as they are installed.  By switching off the hash function, our
+"interactive" commands (<userinput>make</userinput>,
+<userinput>patch</userinput>, <userinput>sed</userinput>,
+<userinput>cp</userinput> and so forth) will always use
+the newest available version during the build process.</para>
+
+<para>Setting the user file-creation mask to 022 ensures that newly created
+files and directories are only writable for their owner, but readable and
+executable for anyone.</para>
+ 
 <para>The LFS variable should of course be set to the mount point you
 chose.</para>
 
 <para>The LC_ALL variable controls the localization of certain programs,
 making their messages follow the conventions of a specified country. If your
 host system uses a version of <emphasis>glibc</emphasis> older than 2.2.4,
-having LC_ALL set to something other than "C" or "POSIX" during this chapter
+having LC_ALL set to something other than "POSIX" or "C" during this chapter
 may cause trouble if you exit the chroot environment and wish to return later.
-By setting LC_ALL to "POSIX" ("C" is an alias for "POSIX") we ensure that
+By setting LC_ALL to "POSIX" (or "C", the two are equivalent)  we ensure that
 everything will work as expected in the chroot environment.</para>
 
-<para>LDFLAGS is a variable we set in order to prevent debugging symbols from
-being compiled into our static packages. By omitting these symbols during
-the linking stage of compilation, we save hard drive space and decrease our
-build time.</para>
+<para>We prepend <filename>/stage1/bin</filename> to the standard PATH so
+that, as we move along through this chapter, the tools we build will get used
+during the rest of the building process.</para>
 
-<para>We are now prepared to begin building the temporary tools which will
-support us in later chapters.</para>
+<para>Now, after sourcing the just-created profile, we're all set to begin
+building the temporary tools that will support us in later chapters.</para>
 
 </sect1>
 

chapter05/whystatic.xml

@@ -42,23 +42,14 @@ of the improved function.</para>
 memory space, disk space, and recompile time.</para>
 
 <para>But if dynamic linking saves so much space, why then are we linking
-all programs in this chapter statically? The reason is that we won't be
-compiling a temporary <filename>glibc</filename> here. And we avoid doing this
-simply to save some time -- around 14 SBUs. Another reason is that the
-Glibc version on the LFS system might not be compatible with the Glibc on
-the host system. Applications compiled against your host system's Glibc
-version may not run properly (or at all) on the LFS system.</para>
-
-<para>This means that the tools compiled in this chapter will have to be
-self-contained, because when later on we chroot to the LFS partition the
-GNU library won't be available. That is why we use the
-<userinput>-static</userinput>, <userinput>--enable-static-link</userinput>,
-and <userinput>--disable-shared</userinput> flags throughout this chapter, to
-ensure that all executables are statically linked. When we come to the next
-chapter, almost the first thing we do is build <filename>glibc</filename>, the
-main set of system libraries. Once this is done, we can link all other programs
-dynamically (including the ones installed statically in this chapter) and
-take advantage of the space saving opportunities.</para>
+the first two packages in this chapter statically? The reason is to make them
+independent from the libraries on your host system. And the point in that is
+that, if you are pressed for time, you could skip the second passes over GCC
+and Binutils, and just use the static versions to compile the rest of this
+chapter and the first few packages in the next. As in the next chapter we
+will be chrooted to the LFS partition and your host system's Glibc won't be
+available, the programs from GCC and Binutils will need to be self-contained,
+that is statically linked.</para>
 
 </sect1>