Changeset 450ac18


Ignore:
Timestamp:
08/20/2022 07:23:37 AM (20 months ago)
Author:
Pierre Labastie <pierre.labastie@…>
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)
Message:

Update and tidy up the page about libraries

Prompted by a somewhat unhelpful comment in a mail of R Tegner.

File:
1 edited

Legend:

Unmodified
Added
Removed

  • introduction/important/libraries.xml

    r0c953f12 r450ac18  
    2323    <title>Libraries: Static or shared?</title>
    2424
    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>
    2932
    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>) &ndash;
     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>
    3441
    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>
    4252
    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>
    4566
    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 &ndash;
     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
    6382    <para>Most libraries are shared, but if you do something unusual, such as
    6483    moving a shared library to <filename class="directory">/lib</filename>
    … …  
    6786    library in <filename class="directory">/lib</filename>, the static library
    6887    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>
    81107
    82108<!-- versions hardcoded in this para, it's a comment on those versions  -->
    … …  
    92118    library which is only used by the programs within the package and,
    93119    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 &ndash; if
     121    the package has to be rebuilt to fix a bug or vulnerability, nothing else is    linked to them.</para>
    97122
    98123    <para>When BLFS mentions system libraries, it means shared versions of
    99124    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 &ndash; sometimes developers go to the trouble of
     128    fixing bugs in their included libraries, other times they do not.</para>
    105129
    106     <para>Sometimes, deciding to use system libraries is an easy decision. Other
    107     times it may require you to alter the system version (e.g. for
     130    <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
    108132    <xref linkend="libpng"/> if used for <xref linkend="firefox"/>).
    109133    Occasionally, a package ships an old library and can no longer link to
    … …  
    112136    is no longer developed separately, or its upstream is now the same as the
    113137    package&apos;s upstream and you have no other packages which will use it.
    114     In those cases, you might decide to use the included static library even if
     138    In those cases, you'll be lead to use the included library even if
    115139    you usually prefer to use system libraries.</para>
    116140
Note: See TracChangeset for help on using the changeset viewer.