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

[Joerg Sonnenberger]

On Wed, Apr 08, 2015 at 09:10:46AM -0400, Ed Maste wrote:
> > (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.
> 
> Unless I'm misunderstanding the case you describe here, it still
> works. If I use the demo from PR 23035 but try to use a symbol from
> the indirect dependency lib2.so from main.c I get:
> 
> GNU ld 2.17.50:
> 
> % clang -Wall -g -rpath . -o main main.o lib1.so
> /usr/bin/ld: undefined reference to symbol `fn2' (try adding -l2)
> ././lib2.so: could not read symbols: Bad value
> clang: error: linker command failed with exit code 1 (use -v to see invocation)
> 
> lld:
> 
> % clang -B. -Wall -g -rpath . -o main main.o lib1.so
> Undefined symbol: main.o: fn2
> symbol(s) not found
> clang: error: linker command failed with exit code 1 (use -v to see invocation)

But this is wrong. ELF rules mean that fn2 is in the namespace, so
failing it is an error. This is exactly the buggy GNU ld behavior I
meant.

Joerg