Shared objects should trigger archive entry activation

[davidlattimore]

It looks like currently we're not activating archive entries in response to undefined symbols in shared objects that are provided by the archive entry. This was observed in #826 (comment)

[davidlattimore]

So the fix for this is trivial - delete an if-statement. Unfortunately, removing that if-statement causes a bunch of tests to fail, because we end up with extra DT_NEEDED entries for --as-needed shared objects. e.g. executables where we previously only linked against say libc, we now also link against libm. These extra DT_NEEDED entries are the reason why I originally incorrectly concluded that undefined symbols in shared objects shouldn't cause optional objects (archive entries and --as-needed shared objects) to be activated. There's some other rule, that I'm yet to completely work out.

[davidlattimore]

OK, I think I've basically figured out the rule here.

It seems that GNU ld will consider an --as-needed shared object to not be needed if (a) the only reason it was needed was because of undefined symbols originating in other shared objects and (b) an already loaded shared object directly or indirectly depends on the shared object under consideration.

LLD does much the same. There is one significant difference between them though. LLD seems to apply normalisation to the shared object's path. So if the shared object was previously indirectly loaded via path libfoo.so then later, we --as-needed load it as ./libfoo.so, LLD will suppress that load. GNU ld doesn't appear to apply any such normalisation, so won't suppress it.

I'm somewhat tempted at this point to fix this bug by only triggering loading of archive entries and leave triggering of --as-needed shared objects until later, possibly in conjunction with #897 which is also related to undefined symbols in shared objects and their dependencies and which I'm probably going to work on next anyway.