[lld] Reading undefined symbols from dynamic objects

Joerg Sonnenberger joerg at britannica.bec.de
Tue Sep 3 12:40:47 PDT 2013


On Tue, Sep 03, 2013 at 12:24:21PM -0700, Nick Kledzik wrote:
> 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?

No, simpler. crtbeginS.o contains a weak reference to _Jv_RegisterClasses.
This is used by an optional Java runtime. If I now link two libraries A
and B with this crtbeginS.o and B depends on A, the old logic would
result in an undefined symbol _Jv_RegisterClasses in B. With the change,
it remains a weak reference as it should be.

Joerg



More information about the llvm-commits mailing list