lfs-book/chapter05/whystatic.xml

<sect1 id="ch05-whystatic">
<title>Why we use static linking</title>
<?dbhtml filename="whystatic.html" dir="chapter05"?>

<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>