PR 9805

        * ld.texinfo (--allow-shlib-undefined): Correct description of
        default settings and tidy up the rest of the entry.

1 files changed, 24 insertions, 11 deletions

diff --git a/ld/ld.texinfo b/ld/ld.texinfo
index 49d1743b19..f38386b92d 100644
--- a/ld/ld.texinfo
+++ b/ld/ld.texinfo
@@ -93,7 +93,7 @@ section entitled ``GNU Free Documentation License''.
 @vskip 0pt plus 1filll
 @c man begin COPYRIGHT
 Copyright @copyright{} 1991, 92, 93, 94, 95, 96, 97, 98, 99, 2000, 2001,
-2002, 2003, 2004, 2005, 2006, 2007, 2008 Free Software Foundation, Inc.
+2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
 
 Permission is granted to copy, distribute and/or modify this document
 under the terms of the GNU Free Documentation License, Version 1.3
@@ -1383,21 +1383,34 @@ first definition will be used.
 @kindex --no-allow-shlib-undefined
 @item --allow-shlib-undefined
 @itemx --no-allow-shlib-undefined
-Allows (the default) or disallows undefined symbols in shared libraries.
+Allows or disallows undefined symbols in shared libraries.
 This switch is similar to @option{--no-undefined} except that it
 determines the behaviour when the undefined symbols are in a
 shared library rather than a regular object file.  It does not affect
 how undefined symbols in regular object files are handled.
 
-The reason that @option{--allow-shlib-undefined} is the default is that
-the shared library being specified at link time may not be the same as
-the one that is available at load time, so the symbols might actually be
-resolvable at load time.  Plus there are some systems, (eg BeOS) where
-undefined symbols in shared libraries is normal.  (The kernel patches
-them at load time to select which function is most appropriate
-for the current architecture.  This is used for example to dynamically
-select an appropriate memset function).  Apparently it is also normal
-for HPPA shared libraries to have undefined symbols.
+The default behaviour is to report errors for any undefined symbols
+referenced in shared libraries if the linker is being used to create
+an executable, but to allow them if the linker is being used to create
+a shared library.
+
+The reasons for allowing undefined symbol references in shared
+libraries specified at link time are that:
+
+@itemize @bullet
+@item
+A shared library specified at link time may not be the same as the one
+that is available at load time, so the symbol might actually be
+resolvable at load time.
+@item
+There are some operating systems, eg BeOS and HPPA, where undefined
+symbols in shared libraries are normal.
+
+The BeOS kernel for example patches shared libraries at load time to
+select whichever function is most appropriate for the current
+architecture.  This is used, for example, to dynamically select an
+appropriate memset function.
+@end itemize
 
 @kindex --no-undefined-version
 @item --no-undefined-version