lld -- symbol resolution via indirect dependencies

[Ed Maste]

I've changed the subject since we're straying of the topic of r234378:
it didn't change the behaviour of this case.

On 8 April 2015 at 11:57, Joerg Sonnenberger <joerg at britannica.bec.de> wrote:
>> 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.

It seems this behaviour may have changed over time in the other
linkers. It's a bit tricky to see what happens in various places
because the linker is usually not invoked directly and is at the mercy
of the options passed by the compiler driver.

I looked at gold, GNU ld 2.17.50 and GNU ld 2.25, and it appears that
by default they all have behaviour consistent with the "lld" example
above. I can make that link work with GNU ld 2.25 by passing
--copy-dt-needed - it then behaves as if lib2.so was specified on the
command line as well. 2.17.50 in FreeBSD base doesn't support the
option.

There's a gold PR on this topic as well, now closed as WONTFIX with an
explanation that the behaviour is intentional there.
https://sourceware.org/bugzilla/show_bug.cgi?id=10238

I think that by default it _should_ be an error if main.o depends on a
symbol provided only through an indirect dependency. We can implement
--copy-dt in lld if anyone wants that behaviour, but it seems to be a
mistake to enable it by default.