Applied Alex' patch to rewrite the why-static section, plus some changes of my own

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

2 files changed, 65 insertions, 68 deletions

diff --git a/chapter05/creatingstaticdir.xml b/chapter05/creatingstaticdir.xml
index 9e83b9952..f0b34a542 100644
--- a/chapter05/creatingstaticdir.xml
+++ b/chapter05/creatingstaticdir.xml
@@ -2,19 +2,14 @@
 <title>Creating the $LFS/static directory</title>
 <?dbhtml filename="creatingstaticdir.html" dir="chapter05"?>
 
-<para>As explained in this chapter's introduction, everything we install
-from this chapter will be installed under the <filename
-class="directory">$LFS/static</filename> directory. This way it won't
-pollute the LFS partition with a bunch of temporary files. All we need to
-do is create this directory so we can start installing. Simply run this
-command to create the directory:</para>
+<para>All programs compiled in this chapter will be installed under <filename
+class="directory">$LFS/static</filename> to keep them separate from the
+programs compiled in the next chapter. The programs compiled here are only
+temporary tools and won't be a part of the final LFS system and by keeping them
+in a separate directory, we can later easily throw them away. Create the
+required directory by running the following:</para>
 
 <para><screen><userinput>mkdir $LFS/static</userinput></screen></para>
 
-<para>You may want to move the packages you downloaded in Chapter 3 to this
-<filename class="directory">$LFS/static</filename> directory, perhaps
-create a subdirectory <filename
-class="directory">$LFS/static/src</filename> to keep them in.</para>
-
 </sect1>
 
diff --git a/chapter05/whystatic.xml b/chapter05/whystatic.xml
index b383455b0..9982252a0 100644
--- a/chapter05/whystatic.xml
+++ b/chapter05/whystatic.xml
@@ -1,62 +1,64 @@
 <sect1 id="ch05-whystatic">
-<title>Why do we use static linking?</title>
+<title>Why we use static linking</title>
 <?dbhtml filename="whystatic.html" dir="chapter05"?>
 
-<para>(Thanks to Plasmatic for posting the text on which this is mainly
-based to one of the LFS mailing lists.)</para>
-
-<para>When making (compiling) a program, rather than having to rewrite all the
-functions for dealing with the kernel, hardware, files, etc. every time you
-write a new program, all these basic functions are instead kept in libraries.
-glibc, which you install later, is one of these major libraries, which
-contains code for all the basic functions programs use, like opening files,
-printing information on the screen, and getting feedback from the user. When
-the program is compiled, these libraries of code are linked together with the
-new program, so that it can use any of the functions that the library
-has.</para>
-
-<para>However, these libraries can be very large (for example, libc.a
-can often be around 2.5 MB), so you may not want a separate copy of each
-library attached to the program. Just imagine if you had a simple command
-like ls with an extra 2.5 MB attached to it! Instead of making the library
-an actual part of the program, or statically linked, the library is stored
-as a separate file, which is loaded only when the program needs it. This
-is what we call dynamically linked, as the library is loaded and unloaded
-dynamically, as the program needs it.</para>
-
-<para>So now we have a 1 KB file and a 2.5 MB file, but we still haven't
-saved any space (except maybe RAM until the library is needed). The
-<emphasis>real</emphasis> advantage of dynamically linked libraries is
-that we only need one copy of the library. If <filename>ls</filename> and
-<filename>rm</filename> both use the same library, then we don't need two
-copies of the library, as they can both get the code from the same file.
-Even when in memory, the two programs share the same code, rather than loading
-duplicates into memory. So not only are we saving hard disk space, but also
-precious RAM.</para>
-
-<para>If dynamic linking saves so much room, then why are we making everything
-statically linked? Well, that's because when you chroot into your brand new
-(but very incomplete) LFS environment, these dynamic libraries won't be
-available because they are somewhere else in your old directory tree
-(<filename>/usr/lib</filename> for example) which won't be accessible 
-from within your LFS root (<filename>$LFS</filename>).</para>
-
-<para>So in order for your new programs to run inside the chroot environment
-you need to make sure that the libraries are statically linked when you build
-them, hence the <userinput>--enable-static-link</userinput>, 
-<userinput>--disable-shared</userinput>, and
-<userinput>-static</userinput> flags used
-through Chapter 5. Once in Chapter 6, the first thing we do is build the
-main set of system libraries, glibc. Once this is made we start rebuilding 
-all the programs we just did in Chapter 5, but this time dynamically linked, 
-so that we can take advantage of the space saving opportunities.</para>
-
-<para>And there you have it, that's why you need to use those weird
-<userinput>-static</userinput> flags. If you try building everything 
-without them, you'll see very quickly what
-happens when you chroot into your newly crippled LFS system.</para>
-
-<para>If you want to know more about Dynamically Linked Libraries, consult
-a book or website on programming, especially a Linux-related site.</para>
+<para>Most programs have to perform, beside their specific task, many rather
+common and trivial operations, such as allocating memory, searching
+directories, opening and closing files, reading and writing them, string
+handling, pattern matching, arithmetic, and so on.  Instead of obliging each
+program to reinvent the wheel, the GNU system provides all these basic
+functions ready-made in libraries. The major library on any Linux system is
+<filename>glibc</filename>. To get an idea of what it contains, have a look at
+<filename>glibc/index.html</filename> somewhere on your host system.</para>
+
+<para>There are two ways of linking the functions from a library to a program
+that uses them: statically or dynamically. When a program is linked
+statically, the code of the used functions is included in the executable,
+resulting in a rather bulky program. When a program is dynamically linked,
+what is included is a reference to the linker, the name of the library, and
+the name of the function, resulting in a much smaller executable. This
+executable has the disadvantage of being somewhat slower than a statically
+linked one, as the linking at run time takes a few moments.</para>
+
+<para>Aside form this small drawback, dynamic linking has two major advantages
+over static linking. First, you need only one copy of the executable library
+code on your hard disk, instead of having many copies of the same code included
+into a whole bunch of programs -- thus saving disk space. Second, when several
+programs use the same library function at the same time, only one copy of the
+function's code is required in core -- thus saving memory space.</para>
+
+<para>Nowadays saving a few megabytes of space may not seem like much, but
+many moons ago, when disks were measured in megabytes and core in kilobytes,
+such savings were essential. It meant being able to keep several programs in
+core at the same time and to contain an entire Unix system on just a few disk
+volumes.</para>
+
+<para>A third but minor advantage of dynamic linking is that when a 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>In summary we can say that dynamic linking trades run time against
+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>
 
 </sect1>
+