aboutsummaryrefslogtreecommitdiff
path: root/include/bfdlink.h
diff options
context:
space:
mode:
authorNick Clifton <nickc@redhat.com>2000-12-12 20:53:02 +0000
committerNick Clifton <nickc@redhat.com>2000-12-12 20:53:02 +0000
commitb15ced227131e541f2087ba7ddab5dc657734c62 (patch)
treed131d6f51162fc4ac9504612575219ee56d8eec0 /include/bfdlink.h
parent533245522d64fa85b5e5c3d20b81443aa24b437c (diff)
downloadnewlib-b15ced227131e541f2087ba7ddab5dc657734c62.zip
newlib-b15ced227131e541f2087ba7ddab5dc657734c62.tar.gz
newlib-b15ced227131e541f2087ba7ddab5dc657734c62.tar.bz2
Add link option to allow undefiedn symbols in shared libraries
Diffstat (limited to 'include/bfdlink.h')
-rw-r--r--include/bfdlink.h13
1 files changed, 13 insertions, 0 deletions
diff --git a/include/bfdlink.h b/include/bfdlink.h
index 18c60a5..ae96323 100644
--- a/include/bfdlink.h
+++ b/include/bfdlink.h
@@ -201,6 +201,19 @@ struct bfd_link_info
/* true if BFD should generate errors for undefined symbols
even if generating a shared object. */
boolean no_undefined;
+ /* true if BFD should allow undefined symbols in shared objects even
+ when no_undefined is set to disallow undefined symbols. 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. */
+ boolean allow_shlib_undefined;
/* Which symbols to strip. */
enum bfd_link_strip strip;
/* Which local symbols to discard. */