[LLVMdev] [lld] [mach-o]: RFC: representing LC_REEXPORT_DYLIB

[Tim Northover]

> Perhaps at the end of DarwinLdDriver::parse() after the nodes are created
> for all the command line files, the driver can iterate over the nodes and
> instantiate any indirect dylibs needed?

That seems to be taking over from Driver::link, which very carefully
dispatches object parsing to a bunch of tasks to do it in parallel (we
obviously don't know what's LC_REEXPORT_DYLIBed until we have parsed
the input file). It would seem better if we could find a way the left
it doing that job.

> You don’t want to load the
> indirect dylibs as each direct dylib is loaded because one of the indirect
> ones may later turn out to be a direct one, and the order determines
> the two-level-namespace ordinal used which we want to remain deterministic.

Ah, I'd not considered anything like that. Presumably this issue goes
beyond the directly specified libraries too (i.e. it matters which
directly specified library a symbol gets associated with, even if it
doesn't come from one).

That probably rules out a simple depth-first InputGraph, but makes
constructing a correct one a bit tricky. I'll have to play around, I
think.

> Shankar, Does lld for ELF support loading indirect DSOs?

I've looked into the ELF situation a bit more (thanks Joerg, for
supplying the initial hints!). It seems to date back to the thread in
[1] (with some background at [2]), where they changed the default from
automatically copying DT_NEEDED entries to requiring a command-line
override for it (personally, I think that was probably the right
decision).

But either way it means that ELF will probably need this ability
eventually, exposed via a "--copy-dt-needed-entries" option if nothing
else.

Cheers.

Tim.

[1] https://sourceware.org/ml/binutils/2011-08/msg00129.html
[2] http://fedoraproject.org/wiki/UnderstandingDSOLinkChange