Changeset 450ac18 for introduction/important
- Timestamp:
- 08/20/2022 07:23:37 AM (20 months ago)
- Branches:
- 11.2, 11.3, 12.0, 12.1, kea, ken/TL2024, ken/inkscape-core-mods, ken/tuningfonts, lazarus, lxqt, plabs/newcss, plabs/python-mods, python3.11, qt5new, rahul/power-profiles-daemon, renodr/vulkan-addition, trunk, xry111/llvm18, xry111/soup3, xry111/xf86-video-removal
- Children:
- 403a9c62
- Parents:
- 0c953f12
- git-author:
- Pierre Labastie <pierre.labastie@…> (08/20/2022 07:20:46 AM)
- git-committer:
- Pierre Labastie <pierre.labastie@…> (08/20/2022 07:23:37 AM)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
introduction/important/libraries.xml
r0c953f12 r450ac18 23 23 <title>Libraries: Static or shared?</title> 24 24 25 <para>The original libraries were simply an archive of routines from which 26 the required routines were extracted and linked into the executable program. 27 These are described as static libraries (libfoo.a). On some old operating 28 systems they are the only type available.</para> 25 <para> 26 The original libraries were simply an archive of routines from which 27 the required routines were extracted and linked into the executable 28 program.These are described as static libraries, with names of the form 29 <filename>libfoo.a</filename> on UNIX-like operating systems. 30 On some old operating systems they are the only type available. 31 </para> 29 32 30 <para>On almost all Linux platforms there are also shared libraries 31 (libfoo.so) - one copy of the library is loaded into virtual memory, and 32 shared by all the programs which call any of its functions. This is space 33 efficient.</para> 33 <para> 34 On almost all Linux platforms there are also <quote>shared</quote> 35 (or equivalently <quote>dynamic</quote>) 36 libraries (with names of the form <filename>libfoo.so</filename>) – 37 one copy of the library is loaded into virtual memory, and shared by 38 all the programs which call any of its functions. This is space 39 efficient. 40 </para> 34 41 35 <para>In the past, essential programs such as a shell were often linked 36 statically so that some form of minimal recovery system would exist even if 37 shared libraries, such as libc.so, became damaged (e.g. moved to 38 <filename class="directory">lost+found</filename> after fsck following an 39 unclean shutdown). Nowadays, most people use an alternative system install 40 or a Live CD if they have to recover. Journaling filesystems also reduce 41 the likelihood of this sort of problem.</para> 42 <para> 43 In the past, essential programs such as a shell were often linked 44 statically so that some form of minimal recovery system would exist even 45 if shared libraries, such as <filename>libc.so</filename>, became 46 damaged (e.g. moved to <filename class="directory">lost+found</filename> 47 after <command>fsck</command> following an unclean shutdown). Nowadays, 48 most people use an alternative system install or a USB stick if they 49 have to recover. Journaling filesystems also reduce the likelihood of 50 this sort of problem. 51 </para> 42 52 43 <para>Developers, at least while they are developing, often prefer to use 44 static versions of the libraries which their code links to.</para> 53 <!-- really? 54 <para> 55 Developers, at least while they are developing, often prefer to use 56 static versions of the libraries which their code links to. 57 </para> 58 --> 59 <para> 60 Within the book, there are various places where configure switches 61 such as <parameter>--disable-static</parameter> are employed, and 62 other places where the possibility of using system versions of 63 libraries instead of the versions included within another package is 64 discussed. The main reason for this is to simplify updates of libraries. 65 </para> 45 66 46 <para>Within the book, there are various places where configure switches 47 such as <command>--disable-static</command> are employed, and other places 48 where the possibility of using system versions of libraries instead of the 49 versions included within another package is discussed. The main reason for 50 this is to simplify updates of libraries.</para> 51 52 <para>If a package is linked to a dynamic library, updating to a newer 53 library version is automatic once the newer library is installed and the 54 program is (re)started (provided the library major version is unchanged, 55 e.g. going from libfoo.so.2.0 to libfoo.so.2.1. Going to libfoo.so.3 56 will require recompilation - <command>ldd</command> can be used to find 57 which programs use the old version). If a program is linked to a static 58 library, the program always has to be recompiled. If you know which 59 programs are linked to a particular static library, this is merely an 60 annoyance. But usually you will <emphasis>not</emphasis> know which 61 programs to recompile.</para> 62 67 <para> 68 If a package is linked to a dynamic library, updating to a newer 69 library version is automatic once the newer library is installed and the 70 program is (re)started (provided the library major version is unchanged, 71 e.g. going from <filename>libfoo.so.2.0</filename> to 72 <filename>libfoo.so.2.1</filename>. Going to 73 <filename>libfoo.so.3</filename> will require recompilation – 74 <command>ldd</command> can be used to find which programs use the old 75 version). If a program is linked to a static 76 library, the program always has to be recompiled. If you know which 77 programs are linked to a particular static library, this is merely an 78 annoyance. But usually you will <emphasis>not</emphasis> know which 79 programs to recompile. 80 </para> 81 <!-- obsolete with /usr merge 63 82 <para>Most libraries are shared, but if you do something unusual, such as 64 83 moving a shared library to <filename class="directory">/lib</filename> … … 67 86 library in <filename class="directory">/lib</filename>, the static library 68 87 will be silently linked into the programs which need it.</para> 69 70 <para>One way to identify when a static library is used, is to deal with it 71 at the end of the installation of every package. Write a script to find all 72 the static libraries in <filename class="directory">/usr/lib</filename> or 73 wherever you are installing to, and either move them to another directory so 74 that they are no longer found by the linker, or rename them so that libfoo.a 75 becomes e.g. libfoo.a.hidden. The static library can then be temporarily 76 restored if it is ever needed, and the package needing it can be 77 identified. You may choose to exclude some of the static libraries from 78 glibc if you do this (<filename>libc_nonshared.a, libg.a, libieee.a, libm.a, 79 libpthread_nonshared.a, librpcsvc.a, libsupc++.a</filename>) to simplify 80 compilation.</para> 88 --> 89 <para> 90 One way to identify when a static library is used, is to deal with 91 it at the end of the installation of every package. Write a script 92 to find all the static libraries in <filename 93 class="directory">/usr/lib</filename> or wherever you are installing 94 to, and either move them to another directory so that they are no 95 longer found by the linker, or rename them so that 96 <filename>libfoo.a</filename> becomes 97 e.g. <filename>libfoo.a.hidden</filename>. The static library can then 98 be temporarily restored if it is ever needed, and the package needing 99 it can be identified. This shoudn't be done blindly since many 100 libraries only exist in a static version. For example, some libraries 101 from the <application>glibc</application> and 102 <application>gcc</application> packages should always be 103 present on the system (<filename>libc_nonshared.a, libg.a, 104 libpthread_nonshared.a, libssp_nonshared.a, libsupc++.a</filename> 105 as of glibc-2.36 and gcc-12.2). 106 </para> 81 107 82 108 <!-- versions hardcoded in this para, it's a comment on those versions --> … … 92 118 library which is only used by the programs within the package and, 93 119 crucially, the library is <emphasis>not</emphasis> installed as a 94 standalone library. These internal libraries are not a problem - if the 95 package has to be rebuilt to fix a bug or vulnerability, nothing else is 96 linked to them.</para> 120 standalone library. These internal libraries are not a problem – if 121 the package has to be rebuilt to fix a bug or vulnerability, nothing else is linked to them.</para> 97 122 98 123 <para>When BLFS mentions system libraries, it means shared versions of 99 124 libraries. Some packages such as <xref linkend="firefox"/> and 100 <xref linkend="gs"/> include many other libraries. When they link to them, 101 they link statically so this also makes the programs bigger. The version 102 they ship is often older than the version used in the system, so it may 103 contain bugs - sometimes developers go to the trouble of fixing bugs in 104 their included libraries, other times they do not.</para> 125 <xref linkend="gs"/> bundle many other libraries in their build tree. 126 The version they ship is often older than the version used in the system, 127 so it may contain bugs – sometimes developers go to the trouble of 128 fixing bugs in their included libraries, other times they do not.</para> 105 129 106 <para>Sometimes, deciding to use system libraries is an easy decision. Other107 times it may require you to alter the system version (e.g. for130 <para>Sometimes, deciding to use system libraries is an easy decision. 131 Other times it may require you to alter the system version (e.g. for 108 132 <xref linkend="libpng"/> if used for <xref linkend="firefox"/>). 109 133 Occasionally, a package ships an old library and can no longer link to … … 112 136 is no longer developed separately, or its upstream is now the same as the 113 137 package's upstream and you have no other packages which will use it. 114 In those cases, you might decide to use the included staticlibrary even if138 In those cases, you'll be lead to use the included library even if 115 139 you usually prefer to use system libraries.</para> 116 140
Note:
See TracChangeset
for help on using the changeset viewer.