aboutsummaryrefslogtreecommitdiff
path: root/ld/ld.texinfo
diff options
context:
space:
mode:
authorNick Clifton <nickc@redhat.com>2003-02-17 18:24:40 +0000
committerNick Clifton <nickc@redhat.com>2003-02-17 18:24:40 +0000
commitae9a127f867f404d20b8010b401ca9aaae9018d9 (patch)
tree94d0a4d7d0df63c27d7405fca51c7b572890e0d7 /ld/ld.texinfo
parentb5f852ea83a8b30b97837afa7b1cf2c87c013998 (diff)
downloadgdb-ae9a127f867f404d20b8010b401ca9aaae9018d9.zip
gdb-ae9a127f867f404d20b8010b401ca9aaae9018d9.tar.gz
gdb-ae9a127f867f404d20b8010b401ca9aaae9018d9.tar.bz2
Fix the behaviour of --allow-shlib-undefined, so that it does what it claims
to do. Add an inverse switch. Update the documentation.
Diffstat (limited to 'ld/ld.texinfo')
-rw-r--r--ld/ld.texinfo34
1 files changed, 22 insertions, 12 deletions
diff --git a/ld/ld.texinfo b/ld/ld.texinfo
index 412ea88..0255662 100644
--- a/ld/ld.texinfo
+++ b/ld/ld.texinfo
@@ -1108,8 +1108,10 @@ while linking a large executable.
@item --no-undefined
@itemx -z defs
Normally when creating a non-symbolic shared library, undefined symbols
-are allowed and left to be resolved by the runtime loader. These options
-disallows such undefined symbols.
+are allowed and left to be resolved by the runtime loader. This option
+disallows such undefined symbols if they come from regular object
+files. The switch @samp{--no-allow-shlib-undefined} controls the
+behaviour for shared objects being linked into the shared library.
@kindex --allow-multiple-definition
@kindex -z muldefs
@@ -1120,17 +1122,25 @@ report a fatal error. These options allow multiple definitions and the
first definition will be used.
@kindex --allow-shlib-undefined
+@kindex --no-allow-shlib-undefined
@item --allow-shlib-undefined
-Allow undefined symbols in shared objects even when --no-undefined is
-set. The net result will be that undefined symbols in regular objects
-will still trigger an error, but undefined symbols in shared objects
-will be ignored. The implementation of no_undefined makes the
-assumption that the runtime linker will choke on undefined symbols.
-However there is at least one system (BeOS) where undefined symbols in
-shared libraries is normal since the kernel patches them at load time to
-select which function is most appropriate for the current architecture.
-I.E. dynamically select an appropriate memset function. Apparently it
-is also normal for HPPA shared libraries to have undefined symbols.
+@itemx --no-allow-shlib-undefined
+Allow (the default) or disallow undefined symbols in shared objects.
+The setting of this switch overrides @samp {--no-undefined} where
+shared objects are concerned. Thus if @samp {--no-undefined} is set
+but @samp {--no-allow-shlib-undefined} is not, the net result will be
+that undefined symbols in regular object files will trigger an error,
+but undefined symbols in shared objects will be ignored.
+
+The reason that @samp{--allow-shlib-undefined} is the default is that
+the shared object being specified at link time may not be the same 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 since the kernel
+patches them at load time to select which function is most appropriate
+for the current architecture. eg. to dynamically select an appropriate
+memset function. Apparently it is also normal for HPPA shared
+libraries to have undefined symbols.
@kindex --no-undefined-version
@item --no-undefined-version