Index: introduction/important/libraries.xml
===================================================================
--- introduction/important/libraries.xml	(revision 6ed5123a4a630871ecf175fbea82aee63ccde617)
+++ introduction/important/libraries.xml	(revision 6ed5123a4a630871ecf175fbea82aee63ccde617)
@@ -0,0 +1,119 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+   "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+  <!ENTITY % general-entities SYSTEM "../../general.ent">
+  %general-entities;
+]>
+
+<sect1 id="libraries" xreflabel="libraries">
+  <?dbhtml filename="libraries.html"?>
+
+  <sect1info>
+    <othername>$LastChangedBy$</othername>
+    <date>$Date$</date>
+  </sect1info>
+
+  <title>Libraries: static or shared</title>
+
+  <!-- section g : 'Others' in longindex.html -->
+  <indexterm zone="libraries">
+    <primary sortas="g-libraries">libraries: static or shared</primary>
+  </indexterm>
+
+  <sect2 role="package">
+    <title>Libraries: static or shared</title>
+
+    <para>The original libraries were simply an archive of routines, from which
+    the required routines were extracted and linked into the executable program.
+    These are described as static libraries (libfoo.a).  On some old operating
+    systems they are the only type available.</para>
+
+    <para>On almost all Linux platforms we also have shared libraries (libfoo.so)
+    - one copy of the library is loaded into vitual memory, and shared by all the
+    programs which call any of its functions. This is space efficient.</para>
+
+    <para>In the past, essential programs such as a shell were often linked
+    statically so that some form of minimal recovery system would exist even if
+    shared libraries, such as libc.so, became damaged (e,g, moved to
+    <filename class="directory">lost+found</filename> after fsck following an
+    unclean shutdown). Nowadays, most people use an alternative system install,
+    or a Live CD, if they have to recover. Journalling filesystems also reduce
+    the likelihood of this sort of problem.</para>
+
+    <para>Developers, at least while they are developing, often prefer to use
+    static versions of the libraries which their code links to.</para>
+
+    <para>Within the book, there are various places where configure switches
+    such as <command>--disable-static</command> are employed, and other places
+    where the possibility of using system versions of libraries instead of the
+    versions included within another package is discussed. The main reason for
+    this is to simplify updates of libraries.</para>
+
+    <para>If a package is linked to a dynamic library, updating to a newer
+    library version is automatic once the newer library is installed and the
+    program is (re)started (provided the library major version is unchanged,
+    e.g. going from from libfoo.so.2.0 to libfoo.so.2.1 : going to libfoo.so.3
+    will require recompilation - use <command>ldd</command> to find what uses
+    the old version). If a program is linked to a static library, the program
+    always has to be recompiled. If you know which programs linked to a
+    particular static library, this is merely an annoyance. But usually you will
+    <emphasis>not</emphasis> know which programs to recompile.</para>
+
+    <para>Most libraries are shared, but if you do something unusual such as
+    moving a shared library to <filename class="directory">/lib</filename> and
+    accidentally break the <literal>.so</literal> symlink in
+    <filename class="directory">/usr/lib</filename> but keep the static library
+    there, the static library will be silently linked into the programs which
+    need it.</para>
+
+    <para>One way to identify when a static library is used is to deal with it
+    at the end of the installation of every package.  Write a script to find all
+    the static libraries in /usr/lib or wherever you are installing to, and
+    either move them to another directory so that they are no longer found by
+    the linker, or rename them so that libfoo.a becomes e.g. libfoo.a.hidden.
+    You can then temporarily restore a static library if it is ever needed, and
+    make a note which package needs it.  You may choose to exclude some of the
+    static libraries from glibc if you do this (<filename>libc_nonshared.a,
+    libg.a, libieee.a, libm.a, libpthread_nonshared.a, librpcsvc.a,
+    libsupc++.a</filename> to simplify compilation.</para>
+
+<!-- versions hardcoded in this para, it's a comment on those versions  -->
+    <para>If you do that, you may discover that more packages than you were
+    expecting use a static library. That was the case with
+    <application>nettle-2.4</application> in its default static-only configuration:
+    required by <application>GnuTLS-3.0.19</application> but also linked into
+    package(s) which used that, such as
+    <application>glib-networking-2.32.3</application>.</para>
+
+    <para>Many packages put some of their common functions into a static
+    library which is only used by the programs within the package and
+    crucially is <emphasis>not</emphasis> installed as a standalone library.
+    These internal libraries are not a problem - if the package has to be
+    rebuilt to fix a bug or vulnerability, nothing else is linked to them.
+    </para>
+
+    <para>When we speak of System libraries, we mean the shared versions. Some
+    packages such as <xref linkend="firefox"/> and <xref linkend="gs"/> include
+    many other libraries. When they link to them, they link statically so this
+    also makes the programs bigger. The version they ship is often older than
+    the version used in the system, so it may contain bugs - sometimes
+    developers go to the trouble of fixing bugs in their included libraries,
+    other times they do not.</para>
+
+    <para>Sometimes, deciding to use system libraries is an easy decision. Other
+    times it may require you to alter the system version (e.g. for
+    <xref linkend="libpng"/> if used for <xref linkend="firefox"/>).
+    Occasionally a package has an old shipped library, can no longer link to the
+    current version, but can link to a less-old version : the book will usually
+    just use the shipped version. Sometimes the included library is no longer
+    developed separately, or its upstream is now the same as the package&apos;s
+    upstream and you have no other packages which will use it. In those cases,
+    you might decide to use the included static library even if you usually
+    prefer to use system libraries.</para>
+
+    <para condition="html" role="usernotes">User Notes:
+    <ulink url="&blfs-wiki;/libraries"/></para>
+
+  </sect2>
+
+</sect1>
