[PATCH] D57385: [ELF] Support --{,no-}allow-shlib-undefined

[Rui Ueyama via llvm-commits]

On Wed, Jan 30, 2019 at 6:05 AM Joerg Sonnenberger via Phabricator <
reviews at reviews.llvm.org> wrote:

> joerg added a comment.
>
> Neither GNU ld nor gold implement really useful behavior here. Ideally,
> every library would be linked with -z defs, but that normally doesn't work
> because on many systems certain symbols are imported from the main program
> by default. A good example are the entry points of the dynamic linker. A
> bad example historically speaking is libwrap. From a user perspective it
> would be desirable to have a way to say "This symbol will be supplied by
> someone else" when linking a shared library or potentially even the main
> binary. That would allow whitelisting intentionally undefined symbols and
> allow avoiding any symbol resolution dance for shared libraries. A single
> pass over the symbol tables is still necessary for the sake of knowing the
> defined symbols and for potential copy relocations, but no further work
> should be needed.
>

I think this feature is useful since you can catch errors at
static-link-time that would otherwise be run-time errors. I agree that the
way how this is implemented is rather ad-hoc; for the linker, there's no
way to distinguish symbols that are intentionally left undefined from ones
that are undefined by mistake. But still this is a widely accepted feature,
and it is better than nothing.

There's a concern though. gold ignores undefined symbols in system
libraries in some specific directories (e.g. /lib or usr/lib) as a
heuristic to not emit a false warning, as the libraries in the system
directory tend to have undefined symbols that are resolved by the loader in
a special manner.

Ray, did you try building something with this patch? Didn't you see any
false errors?


> Repository:
>   rLLD LLVM Linker
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D57385/new/
>
> https://reviews.llvm.org/D57385
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20190130/9f226b2f/attachment.html>