[PATCH] D12226: [LLD] Support for --unresolved-symbols option in llvm lld for ELF file format

Rui Ueyama via llvm-commits llvm-commits at lists.llvm.org
Thu Sep 3 08:19:25 PDT 2015


On Thu, Sep 3, 2015 at 8:44 PM, Joerg Sonnenberger via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> On Thu, Sep 03, 2015 at 04:52:34AM +0000, Shridhar Joshi via llvm-commits
> wrote:
> > joshishr added a comment.
> >
> > In http://reviews.llvm.org/D12226#238177, @joerg wrote:
> >
> > > The undefined-shlib case makes no sense. That's exactly the case I am
> talking about.
> >
> >
> > --[no]-allow-shlib-undefined option is shared library specific.
>
> It is not given the way it is implemented. It is kind of an equivalent
> to -z,defs, but not really. None of the existing options should report
> undefined symbols in a shared library we are linking against. This is
> completely different from whether or not we should allow undefined
> symbols if we are *creating* a shared library. Do you see the
> difference?
>

I think I agree with Joerg. When we are just using a DSO, it doesn't make
sense to warn on undefined symbols in the DSO.

Your test case looks like it's testing against that
case. libfoo_unresolved-symbols.so has undefined symbols in it, and the
test is testing if LLD print error messages on it when linking against
libfoo_unresolved-symbols.so.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150904/c43d83fc/attachment.html>


More information about the llvm-commits mailing list