[lld] r234378 - Allow undefined symbols in shared library by default.

[Joerg Sonnenberger]

On Wed, Apr 08, 2015 at 07:53:01AM -0400, Rafael Espíndola wrote:
> > Are you sure this is correct? There are two different cases here:
> > (1) The undefined symbol is in a dependency. While it is sometimes nice
> > to see a warning, it should not be an error. GNU ld gets this wrong.
> >
> > (2) The undefined symbol is defined in a dependency. I think we get this
> > wrong right now for indirect dependencies, e.g. we link against libfoo,
> > which links against libbar and the symbol is defined by libbar. We
> > certainly *do* want to complain by default here.
> 
> Can you give an example of both cases?

libwrap requires the main program to supply globals like allow_severity.
This means trying to link against libwrap will almost always see it as
having missing symbols. This is bad design, but reality.

The second case is easier. libc++ is linked against libm, the main
program links against libc++ and uses e.g. pow(3). It is not undefined
in the ELF sense as libm provides it. GNU ld (both BFD and GOLD) decided
to screw the ELF semantic in later version by complaining in this case,
but this is actually quite important if you change the perspective from
defining the ABI as "libfoo provides bar" to "libfoo ensures that bar is
available". The ELF behavior is fundamentally the latter case and all
dependencies have to be scanned for correct COPY relocations anyway.

> In general the thing I find broken about the bfd ld behavior is that
> it is  presumptuous for the static linker to think it knows how the
> dynamic one will do its job.

Yes and no. The static linker has to be implement the same rules for
various cases. As mentioned above, COPY relocations are a good example.
What I find broken about GNU ld is that they decided to change the rules
for the static linker without any advantage for the dynamic one.

> For example, if libxml.so has support for using zlib compression, one
> build of it can include zlib and another might link with libzlib.so.
> Both export the same interface, it is not the static linker's job to
> go check for libzlib.so. In a distributed build, it shouldn't even be
> necessary to have libzlib.so available to link with libxml.so.

This is similar to the example above. Yes, it should look for libz.so
if libxml.so is linked against it. It can't get a correct view of the
global namespace otherwise.

Joerg