In ld.bfd/gold, --no-allow-shlib-undefined is the default when linking
an executable. If a DSO on the command line has an unresolvedThis patch implements a check to error on undefined
reference, and all of its DT_NEEDED entries are seensymbols in a shared object, a warning is
issuedif all of its DT_NEEDED entries are seen.
This warning is issued based on the symbol tableOur approach resembles the one used in gold, different fromachieves a good balance to
be useful but not too smart (ld.bfd traces all DSOs and emulates the
undefined reference errors issued for relocationsbehavior of a dynamic linker to catch more cases).
The cases warnerror is issued by --allow-shlib-undefined are runtime errors (ld.so:ased on the symbol table, different from undefined
unknown symbol) that are really link-time problemsreference errors issued for relocations. It is most effective when there
when there are DSOs that were not linked with -z,-z defs (e.g. when static sanitizers
sanitizers runtime is used).
gold has a comment that some system libraries on GNU/Linux may have
spurious warningsundefined references and thus system libraries should be excluded.
excluded (https://sourceware.org/bugzilla/show_bug.cgi?id=6811). The
The statusstory may have changed now but we make --allow-shlib-undefined the
default for now. Its interaction with -shared can be discussed in the