1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
|
<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. Under
certain circumstances, this executable can have the disadvantage of being
somewhat slower than a statically linked one, as the linking at run time takes
a few moments. It should be noted, however, that under normal circumstances on
today's hardware, a dynamically linked executable will be faster than a
statically linked one as the library function being called by the dynamically
linked executable has a good chance of already being loaded in your system's
RAM.</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>
|
