Changeset 4d51529 for chapter05/whystatic.xml
- Timestamp:
- 01/03/2003 02:51:46 AM (21 years ago)
- Branches:
- 10.0, 10.0-rc1, 10.1, 10.1-rc1, 11.0, 11.0-rc1, 11.0-rc2, 11.0-rc3, 11.1, 11.1-rc1, 11.2, 11.2-rc1, 11.3, 11.3-rc1, 12.0, 12.0-rc1, 12.1, 12.1-rc1, 6.0, 6.1, 6.1.1, 6.3, 6.4, 6.5, 6.6, 6.7, 6.8, 7.0, 7.1, 7.2, 7.3, 7.4, 7.5, 7.5-systemd, 7.6, 7.6-systemd, 7.7, 7.7-systemd, 7.8, 7.8-systemd, 7.9, 7.9-systemd, 8.0, 8.1, 8.2, 8.3, 8.4, 9.0, 9.1, arm, bdubbs/gcc13, ml-11.0, multilib, renodr/libudev-from-systemd, s6-init, trunk, v4_1, v5_0, v5_1, v5_1_1, xry111/arm64, xry111/arm64-12.0, xry111/clfs-ng, xry111/lfs-next, xry111/loongarch, xry111/loongarch-12.0, xry111/loongarch-12.1, xry111/mips64el, xry111/pip3, xry111/rust-wip-20221008, xry111/update-glibc
- Children:
- 72bab45
- Parents:
- 3cf0fef
- File:
-
- 1 edited
-
chapter05/whystatic.xml (modified) (1 diff)
Legend:
- Unmodified
- Added
- Removed
-
chapter05/whystatic.xml
r3cf0fef r4d51529 1 1 <sect1 id="ch05-whystatic"> 2 <title>Why do we use static linking?</title>2 <title>Why we use static linking</title> 3 3 <?dbhtml filename="whystatic.html" dir="chapter05"?> 4 4 5 <para>(Thanks to Plasmatic for posting the text on which this is mainly 6 based to one of the LFS mailing lists.)</para> 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> 7 13 8 <para>When making (compiling) a program, rather than having to rewrite all the 9 functions for dealing with the kernel, hardware, files, etc. every time you 10 write a new program, all these basic functions are instead kept in libraries. 11 glibc, which you install later, is one of these major libraries, which 12 contains code for all the basic functions programs use, like opening files, 13 printing information on the screen, and getting feedback from the user. When 14 the program is compiled, these libraries of code are linked together with the 15 new program, so that it can use any of the functions that the library 16 has.</para> 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> 17 22 18 <para>However, these libraries can be very large (for example, libc.a 19 can often be around 2.5 MB), so you may not want a separate copy of each 20 library attached to the program. Just imagine if you had a simple command 21 like ls with an extra 2.5 MB attached to it! Instead of making the library 22 an actual part of the program, or statically linked, the library is stored 23 as a separate file, which is loaded only when the program needs it. This 24 is what we call dynamically linked, as the library is loaded and unloaded 25 dynamically, as the program needs it.</para> 23 <para>Aside form 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> 26 29 27 <para>So now we have a 1 KB file and a 2.5 MB file, but we still haven't 28 saved any space (except maybe RAM until the library is needed). The 29 <emphasis>real</emphasis> advantage of dynamically linked libraries is 30 that we only need one copy of the library. If <filename>ls</filename> and 31 <filename>rm</filename> both use the same library, then we don't need two 32 copies of the library, as they can both get the code from the same file. 33 Even when in memory, the two programs share the same code, rather than loading 34 duplicates into memory. So not only are we saving hard disk space, but also 35 precious RAM.</para> 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> 36 35 37 <para>If dynamic linking saves so much room, then why are we making everything 38 statically linked? Well, that's because when you chroot into your brand new 39 (but very incomplete) LFS environment, these dynamic libraries won't be 40 available because they are somewhere else in your old directory tree 41 (<filename>/usr/lib</filename> for example) which won't be accessible 42 from within your LFS root (<filename>$LFS</filename>).</para> 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 43 44 <para>So in order for your new programs to run inside the chroot environment 45 you need to make sure that the libraries are statically linked when you build 46 them, hence the <userinput>--enable-static-link</userinput>, 47 <userinput>--disable-shared</userinput>, and 48 <userinput>-static</userinput> flags used 49 through Chapter 5. Once in Chapter 6, the first thing we do is build the 50 main set of system libraries, glibc. Once this is made we start rebuilding 51 all the programs we just did in Chapter 5, but this time dynamically linked, 52 so that we can take advantage of the space saving opportunities.</para> 44 <para>But if dynamic linking saves so much space, why then are we linking 45 all programs in this chapter statically? The reason is that we won't be 46 compiling a temporary <filename>glibc</filename> here. And we avoid doing this 47 simply to save some time -- around 14 SBUs. Another reason is that the 48 Glibc version on the LFS system might not be compatible with the Glibc on 49 the host system. Applications compiled against your host system's Glibc 50 version may not run properly (or at all) on the LFS system.</para> 53 51 54 <para>And there you have it, that's why you need to use those weird 55 <userinput>-static</userinput> flags. If you try building everything 56 without them, you'll see very quickly what 57 happens when you chroot into your newly crippled LFS system.</para> 58 59 <para>If you want to know more about Dynamically Linked Libraries, consult 60 a book or website on programming, especially a Linux-related site.</para> 52 <para>This means that the tools compiled in this chapter will have to be 53 self-contained, because when later on we chroot to the LFS partition the 54 GNU library won't be available. That is why we use the 55 <userinput>-static</userinput>, <userinput>--enable-static-link</userinput>, 56 and <userinput>--disable-shared</userinput> flags throughout this chapter, to 57 ensure that all executables are statically linked. When we come to the next 58 chapter, almost the first thing we do is build <filename>glibc</filename>, the 59 main set of system libraries. Once this is done, we can link all other programs 60 dynamically (including the ones installed statically in this chapter) and 61 take advantage of the space saving opportunities.</para> 61 62 62 63 </sect1> 64
Note:
See TracChangeset
for help on using the changeset viewer.
