Index: introduction/important/libraries.xml
===================================================================
--- introduction/important/libraries.xml	(revision df373d273031aa6ae9cb63cb8ea12332b5f4e62d)
+++ introduction/important/libraries.xml	(revision 450ac1874f2baff02d53a9e5211c8584b9a6fbf9)
@@ -23,42 +23,61 @@
     <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>
+      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, with names of the form
+      <filename>libfoo.a</filename> on UNIX-like operating systems.
+      On some old operating systems they are the only type available.
+    </para>
 
-    <para>On almost all Linux platforms there are also shared libraries
-    (libfoo.so) - one copy of the library is loaded into virtual memory, and
-    shared by all the programs which call any of its functions. This is space
-    efficient.</para>
+    <para>
+      On almost all Linux platforms there are also <quote>shared</quote>
+      (or equivalently <quote>dynamic</quote>)
+      libraries (with names of the form <filename>libfoo.so</filename>) &ndash;
+      one copy of the library is loaded into virtual 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. Journaling filesystems also reduce
-    the likelihood of this sort of problem.</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 <filename>libc.so</filename>, became
+      damaged (e.g. moved to <filename class="directory">lost+found</filename>
+      after <command>fsck</command> following an unclean shutdown). Nowadays,
+      most people use an alternative system install or a USB stick if they
+      have to recover. Journaling 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>
+<!-- really?
+    <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 <parameter>--disable-static</parameter> 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>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 libfoo.so.2.0 to libfoo.so.2.1. Going to libfoo.so.3
-    will require recompilation - <command>ldd</command> can be used to find
-    which programs use the old version). If a program is linked to a static
-    library, the program always has to be recompiled. If you know which
-    programs are 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>
+      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 <filename>libfoo.so.2.0</filename> to
+      <filename>libfoo.so.2.1</filename>. Going to
+      <filename>libfoo.so.3</filename> will require recompilation &ndash;
+      <command>ldd</command> can be used to find which programs use the old
+      version). If a program is linked to a static
+      library, the program always has to be recompiled. If you know which
+      programs are linked to a particular static library, this is merely an
+      annoyance. But usually you will <emphasis>not</emphasis> know which
+      programs to recompile.
+    </para>
+<!-- obsolete with /usr merge
     <para>Most libraries are shared, but if you do something unusual, such as
     moving a shared library to <filename class="directory">/lib</filename>
@@ -67,16 +86,23 @@
     library in <filename class="directory">/lib</filename>, 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 <filename class="directory">/usr/lib</filename> 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. The static library can then be temporarily
-    restored if it is ever needed, and the package needing it can be
-    identified. 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>
+-->
+    <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 <filename
+        class="directory">/usr/lib</filename> 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
+      <filename>libfoo.a</filename> becomes
+      e.g. <filename>libfoo.a.hidden</filename>. The static library can then
+      be temporarily restored if it is ever needed, and the package needing
+      it can be identified. This shoudn't be done blindly since many
+      libraries only exist in a static version. For example, some libraries
+      from the <application>glibc</application> and
+      <application>gcc</application> packages should always be
+      present on the system (<filename>libc_nonshared.a, libg.a,
+        libpthread_nonshared.a, libssp_nonshared.a, libsupc++.a</filename>
+      as of glibc-2.36 and gcc-12.2).
+    </para>
 
 <!-- versions hardcoded in this para, it's a comment on those versions  -->
@@ -92,18 +118,16 @@
     library which is only used by the programs within the package and,
     crucially, the library 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>
+    standalone library. These internal libraries are not a problem &ndash; if
+    the package has to be rebuilt to fix a bug or vulnerability, nothing else is    linked to them.</para>
 
     <para>When BLFS mentions system libraries, it means shared versions of
     libraries. 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>
+    <xref linkend="gs"/> bundle many other libraries in their build tree.
+    The version they ship is often older than the version used in the system,
+    so it may contain bugs &ndash; 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
+    <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 ships an old library and can no longer link to
@@ -112,5 +136,5 @@
     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
+    In those cases, you'll be lead to use the included library even if
     you usually prefer to use system libraries.</para>
 
