From b15ced227131e541f2087ba7ddab5dc657734c62 Mon Sep 17 00:00:00 2001 From: Nick Clifton Date: Tue, 12 Dec 2000 20:53:02 +0000 Subject: Add link option to allow undefiedn symbols in shared libraries --- include/ChangeLog | 7 +++++++ include/bfdlink.h | 13 +++++++++++++ 2 files changed, 20 insertions(+) diff --git a/include/ChangeLog b/include/ChangeLog index 68470925e..1b1af7689 100644 --- a/include/ChangeLog +++ b/include/ChangeLog @@ -1,3 +1,10 @@ +2000-12-10 Fred Fish + + * bfdlink.h (struct bfd_link_info): Add new allow_shlib_undefined + member to struct for systems where it is normal to have undefined + symbols in shared libraries at runtime and the runtime linker takes + care of redirecting them. + 2000-12-07 Zack Weinberg * safe-ctype.h: New file. diff --git a/include/bfdlink.h b/include/bfdlink.h index 18c60a57d..ae96323bf 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. */ -- cgit v1.2.3