1 | <sect1 id="ch05-whystatic">
|
---|
2 | <title>Why we use static linking</title>
|
---|
3 | <?dbhtml filename="whystatic.html" dir="chapter05"?>
|
---|
4 |
|
---|
5 | <para>Most programs have to perform, beside their specific task, many rather
|
---|
6 | common and trivial operations, such as allocating memory, searching
|
---|
7 | directories, opening and closing files, reading and writing them, string
|
---|
8 | handling, pattern matching, arithmetic, and so on. Instead of obliging each
|
---|
9 | program to reinvent the wheel, the GNU system provides all these basic
|
---|
10 | functions ready-made in libraries. The major library on any Linux system is
|
---|
11 | <filename>glibc</filename>. To get an idea of what it contains, have a look at
|
---|
12 | <filename>glibc/index.html</filename> somewhere on your host system.</para>
|
---|
13 |
|
---|
14 | <para>There are two ways of linking the functions from a library to a program
|
---|
15 | that uses them: statically or dynamically. When a program is linked
|
---|
16 | statically, the code of the used functions is included in the executable,
|
---|
17 | resulting in a rather bulky program. When a program is dynamically linked,
|
---|
18 | what is included is a reference to the linker, the name of the library, and
|
---|
19 | the name of the function, resulting in a much smaller executable. This
|
---|
20 | executable has the disadvantage of being somewhat slower than a statically
|
---|
21 | linked one, as the linking at run time takes a few moments.</para>
|
---|
22 |
|
---|
23 | <para>Aside from this small drawback, dynamic linking has two major advantages
|
---|
24 | over static linking. First, you need only one copy of the executable library
|
---|
25 | code on your hard disk, instead of having many copies of the same code included
|
---|
26 | into a whole bunch of programs -- thus saving disk space. Second, when several
|
---|
27 | programs use the same library function at the same time, only one copy of the
|
---|
28 | function's code is required in core -- thus saving memory space.</para>
|
---|
29 |
|
---|
30 | <para>Nowadays saving a few megabytes of space may not seem like much, but
|
---|
31 | many moons ago, when disks were measured in megabytes and core in kilobytes,
|
---|
32 | such savings were essential. It meant being able to keep several programs in
|
---|
33 | core at the same time and to contain an entire Unix system on just a few disk
|
---|
34 | volumes.</para>
|
---|
35 |
|
---|
36 | <para>A third but minor advantage of dynamic linking is that when a library
|
---|
37 | function gets a bug fixed, or is otherwise improved, you only need to recompile
|
---|
38 | this one library, instead of having to recompile all the programs that make use
|
---|
39 | of the improved function.</para>
|
---|
40 |
|
---|
41 | <para>In summary we can say that dynamic linking trades run time against
|
---|
42 | memory space, disk space, and recompile time.</para>
|
---|
43 |
|
---|
44 | <para>But if dynamic linking saves so much space, why then are we linking
|
---|
45 | the first two packages in this chapter statically? The reason is to make them
|
---|
46 | independent from the libraries on your host system. The advantage is that, if
|
---|
47 | you are pressed for time, you could skip the second passes over GCC and
|
---|
48 | Binutils, and just use the static versions to compile the rest of this chapter
|
---|
49 | and the first few packages in the next. In the next chapter we will be
|
---|
50 | chrooted to the LFS partition and once inside the chroot environment, the host
|
---|
51 | system's Glibc won't be available, thus the programs from GCC and Binutils
|
---|
52 | will need to be self-contained, i.e. statically linked. However, we strongly
|
---|
53 | advise <emphasis>against</emphasis> skipping the second passes.</para>
|
---|
54 |
|
---|
55 | </sect1>
|
---|
56 |
|
---|