cvs commit: LFS/BOOK/chapter05 creatingstaticdir.xml whystatic.xml

gerard at gerard at
Thu Jan 2 18:51:46 PST 2003

gerard      03/01/02 21:51:46

  Modified:    BOOK/chapter05 creatingstaticdir.xml whystatic.xml
  Applied Alex' patch to rewrite the why-static section, plus some changes of my own
  Revision  Changes    Path
  1.3       +6 -11     LFS/BOOK/chapter05/creatingstaticdir.xml
  Index: creatingstaticdir.xml
  RCS file: /home/cvsroot/LFS/BOOK/chapter05/creatingstaticdir.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- creatingstaticdir.xml	20 Sep 2002 21:11:27 -0000	1.2
  +++ creatingstaticdir.xml	3 Jan 2003 02:51:46 -0000	1.3
  @@ -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>
  1.13      +59 -57    LFS/BOOK/chapter05/whystatic.xml
  Index: whystatic.xml
  RCS file: /home/cvsroot/LFS/BOOK/chapter05/whystatic.xml,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- whystatic.xml	28 Sep 2002 21:08:28 -0000	1.12
  +++ whystatic.xml	3 Jan 2003 02:51:46 -0000	1.13
  @@ -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
  -<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
  +<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>
Unsubscribe: send email to listar at
and put 'unsubscribe lfs-book' in the subject header of the message

More information about the lfs-book mailing list