Ignore:
File:
1 edited

Legend:

Unmodified
Added
Removed

  • introduction/important/libraries.xml

    r45ab6c7 r3f2db3a6  
    99  <?dbhtml filename="libraries.html"?>
    1010
    11   <sect1info>
    12     <date>$Date$</date>
    13   </sect1info>
    1411
    1512  <title>Libraries: Static or shared?</title>
    … …  
    2320    <title>Libraries: Static or shared?</title>
    2421
    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>
     22    <para>
     23      The original libraries were simply an archive of routines from which
     24      the required routines were extracted and linked into the executable
     25      program. These are described as static libraries, with names of the form
     26      <filename>libfoo.a</filename> on UNIX-like operating systems.
     27      On some old operating systems they are the only type available.
     28    </para>
    2929
    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>
     30    <para>
     31      On almost all Linux platforms there are also <quote>shared</quote>
     32      (or equivalently <quote>dynamic</quote>)
     33      libraries (with names of the form <filename>libfoo.so</filename>) &ndash;
     34      one copy of the library is loaded into virtual memory, and shared by
     35      all the programs which call any of its functions. This is space
     36      efficient.
     37    </para>
    3438
    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>
     39    <para>
     40      In the past, essential programs such as a shell were often linked
     41      statically so that some form of minimal recovery system would exist even
     42      if shared libraries, such as <filename>libc.so</filename>, became
     43      damaged (e.g. moved to <filename class="directory">lost+found</filename>
     44      after <command>fsck</command> following an unclean shutdown). Nowadays,
     45      most people use an alternative system install or a USB stick if they
     46      have to recover. Journaling filesystems also reduce the likelihood of
     47      this sort of problem.
     48    </para>
    4249
    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>
     50<!-- really?
     51    <para>
     52      Developers, at least while they are developing, often prefer to use
     53      static versions of the libraries which their code links to.
     54    </para>
     55-->
     56    <para>
     57      Within the book, there are various places where configure switches
     58      such as <parameter>--disable-static</parameter> are employed, and
     59      other places where the possibility of using system versions of
     60      libraries instead of the versions included within another package is
     61      discussed. The main reason for this is to simplify updates of libraries.
     62    </para>
    4563
    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 
     64    <para>
     65      If a package is linked to a dynamic library, updating to a newer
     66      library version is automatic once the newer library is installed and the
     67      program is (re)started (provided the library major version is unchanged,
     68      e.g. going from <filename>libfoo.so.2.0</filename> to
     69      <filename>libfoo.so.2.1</filename>. Going to
     70      <filename>libfoo.so.3</filename> will require recompilation &ndash;
     71      <command>ldd</command> can be used to find which programs use the old
     72      version). If a program is linked to a static
     73      library, the program always has to be recompiled. If you know which
     74      programs are linked to a particular static library, this is merely an
     75      annoyance. But usually you will <emphasis>not</emphasis> know which
     76      programs to recompile.
     77    </para>
     78<!-- obsolete with /usr merge
    6379    <para>Most libraries are shared, but if you do something unusual, such as
    6480    moving a shared library to <filename class="directory">/lib</filename>
    … …  
    6783    library in <filename class="directory">/lib</filename>, the static library
    6884    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>
     85-->
     86    <para>
     87      One way to identify when a static library is used, is to deal with
     88      it at the end of the installation of every package.  Write a script
     89      to find all the static libraries in <filename
     90        class="directory">/usr/lib</filename> or wherever you are installing
     91      to, and either move them to another directory so that they are no
     92      longer found by the linker, or rename them so that
     93      <filename>libfoo.a</filename> becomes
     94      e.g. <filename>libfoo.a.hidden</filename>. The static library can then
     95      be temporarily restored if it is ever needed, and the package needing
     96      it can be identified. This shouldn't be done blindly since many
     97      libraries only exist in a static version. For example, some libraries
     98      from the <application>glibc</application> and
     99      <application>gcc</application> packages should always be
     100      present on the system (<filename>libc_nonshared.a, libg.a,
     101        libpthread_nonshared.a, libssp_nonshared.a, libsupc++.a</filename>
     102      as of glibc-2.36 and gcc-12.2).
     103    </para>
    81104
    82105<!-- versions hardcoded in this para, it's a comment on those versions  -->
    … …  
    92115    library which is only used by the programs within the package and,
    93116    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>
     117    standalone library. These internal libraries are not a problem &ndash; if
     118    the package has to be rebuilt to fix a bug or vulnerability, nothing else
     119    is linked to them.</para>
    97120
    98121    <para>When BLFS mentions system libraries, it means shared versions of
    99122    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>
     123    <xref linkend="gs"/> bundle many other libraries in their build tree.
     124    The version they ship is often older than the version used in the system,
     125    so it may contain bugs &ndash; sometimes developers go to the trouble of
     126    fixing bugs in their included libraries, other times they do not.</para>
    105127
    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
     128    <para>Sometimes, deciding to use system libraries is an easy decision.
     129    Other times it may require you to alter the system version (e.g. for
    108130    <xref linkend="libpng"/> if used for <xref linkend="firefox"/>).
    109131    Occasionally, a package ships an old library and can no longer link to
    … …  
    112134    is no longer developed separately, or its upstream is now the same as the
    113135    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
     136    In those cases, you'll be lead to use the included library even if
    115137    you usually prefer to use system libraries.</para>
    116138
Note: See TracChangeset for help on using the changeset viewer.