aboutsummaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
Diffstat (limited to 'include')
-rw-r--r--include/ChangeLog9
-rw-r--r--include/bfdlink.h42
2 files changed, 33 insertions, 18 deletions
diff --git a/include/ChangeLog b/include/ChangeLog
index fb8eaf7..971de50 100644
--- a/include/ChangeLog
+++ b/include/ChangeLog
@@ -1,3 +1,12 @@
+2003-08-20 Nick Clifton <nickc@redhat.com>
+
+ * bfdlink.h (enum report_method): New enum. Describes how to
+ report something.
+ (struct bfd_link_info): Delete fields 'no_undefined' and
+ 'allow_shlib_undefined'. Replace with
+ 'unresolved_symbols_in_objects' and
+ 'unresolved_symbols_in_shared_libs'.
+
2003-08-07 Alan Modra <amodra@bigpond.net.au>
* bfdlink.h: Remove PARAMS macro. Replace PTR with void *.
diff --git a/include/bfdlink.h b/include/bfdlink.h
index e8fc65f..c174dcd 100644
--- a/include/bfdlink.h
+++ b/include/bfdlink.h
@@ -198,6 +198,19 @@ struct bfd_sym_chain
const char *name;
};
+/* How to handle unresolved symbols.
+ There are four possibilities which are enumerated below: */
+enum report_method
+{
+ /* This is the initial value when then link_info structure is created.
+ It allows the various stages of the linker to determine whether they
+ allowed to set the value. */
+ RM_NOT_YET_SET = 0,
+ RM_IGNORE,
+ RM_GENERATE_WARNING,
+ RM_GENERATE_ERROR
+};
+
/* This structure holds all the information needed to communicate
between BFD and the linker when doing a link. */
@@ -238,24 +251,6 @@ struct bfd_link_info
need much more time and therefore must be explicitly selected. */
unsigned int optimize: 1;
- /* TRUE if BFD should generate errors for undefined symbols
- even if generating a shared object. */
- unsigned int no_undefined: 1;
-
- /* 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. */
- unsigned int allow_shlib_undefined: 1;
-
/* TRUE if ok to have multiple definition. */
unsigned int allow_multiple_definition: 1;
@@ -305,6 +300,17 @@ struct bfd_link_info
flags. */
unsigned int noexecstack: 1;
+ /* What to do with unresolved symbols in an object file.
+ When producing static binaries the default is GENERATE_ERROR.
+ When producing dynamic binaries the default is IGNORE. The
+ assumption with dynamic binaries is that the reference will be
+ resolved at load/execution time. */
+ enum report_method unresolved_syms_in_objects;
+
+ /* What to do with unresolved symbols in a shared library.
+ The same defaults apply. */
+ enum report_method unresolved_syms_in_shared_libs;
+
/* Which symbols to strip. */
enum bfd_link_strip strip;