https://bugs.llvm.org/show_bug.cgi?id=35635
Bug ID: 35635
Summary: Should we implement --no-allow-shlib-undefined?
Product: lld
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: ELF
Assignee: unassignedb...@nondot.org
Reporter: r...@google.com
CC: llvm-bugs@lists.llvm.org
Currently lld behaves as if --allow-shlib-undefined is given, and there's no
way to check whether undefined symbols in DSOs can be resolved or not.
The lack of the option could result in a bad user experience. For example,
imagine that a user forgot to implement some function in a DSO. The DSO links
fine. And all executables that uses the DSO link fine with lld. But the
executables would fail at run-time because the symbol cannot be resolved by the
dynamic linker. Even worse, they don't always fail at start-up time because of
PLT entries are resolved lazily.
Maybe we should evaluate the impact of implementing --no-allow-shlib-undefined.
If it can be implemented easily, we probably should do that.
--
You are receiving this mail because:
You are on the CC list for the bug._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
