mirror of
https://git.linuxfromscratch.org/lfs.git
synced 2025-01-20 05:57:43 +00:00
fa2e6935d7
git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@2812 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
57 lines
3.2 KiB
XML
57 lines
3.2 KiB
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 from 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
|
|
the first two packages in this chapter statically? The reason is to make them
|
|
independent from the libraries on your host system. The advantage 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. In the next chapter we will be
|
|
chrooted to the LFS partition and once inside the chroot environment, the host
|
|
system's Glibc won't be available, thus the programs from GCC and Binutils
|
|
will need to be self-contained, i.e. statically linked. However, we strongly
|
|
advise <emphasis>against</emphasis> skipping the second passes.</para>
|
|
|
|
</sect1>
|
|
|