[lld] Reading undefined symbols from dynamic objects

[Nick Kledzik]

I read your original post as talking about weak-definitions.   I try to avoid using the term “weak” because it is so overloaded that it has become ambiguous.

In lld, we use “canBeNull” for weak-imports.  

So, is the problem you are trying to solve that normally when a main executable is linked against a shared library (in -no-allow-shilb-undefined mode), the linker recurses down and loads all dependent shared libraries and checks the undefined symbols in each to verify that the main executable can be launched.  But if one of those undefines in a linked shared library is allowed to be missing at runtime (canBeNull), there is no need to check it exists at build time?

-Nick

On Sep 3, 2013, at 12:09 PM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote:
> On Tue, Sep 03, 2013 at 12:03:38PM -0700, Nick Kledzik wrote:
>> Bigger question.  What is the rule for ELF (and PE/COFF) for weak
>> definitions in shared libraries vs object files?
> 
> Good question, I have to check. Note that there are two different cases
> here:
> 
> (1) The weak symbol is defined.
> (2) The weak symbol is not defined.
> 
> This patch is strictly about the second case. If it is a weak reference,
> the result should be different, but I haven't had a chance to build a
> test case for that yet and check if the behavior is correct. Will have
> to do that soon enough as NetBSD's libc exercise that anyway.
> 
> Joerg
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits