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

Tim Northover t.p.northover at gmail.com
Thu Jul 10 05:56:34 PDT 2014


Hi Nick,

On 3 July 2014 01:09, Nick Kledzik <kledzik at apple.com> wrote:
> 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.

I've finally got back to this issue and I'm not sure what you mean
here. My tests suggest that ld64 performs a depth-first search of the
libraries and we *do* want to load them at the same time (or at least
make sure they're considered at the same time for resolution
purposes). For example (reproduced by tmp.sh attached):

$ cat foo.c
int foo() {
  return 'f';
}
$ cat main.c
extern int foo();
int main() {
  return foo();
}
$ cat wrapper.c
$ clang -shared foo.c -olibfoo.dylib
$ clang wrapper.c -shared -Wl,-reexport_library,libfoo.dylib -o libwrapper.dylib
$ clang main.c libwrapper.dylib libfoo.dylib -omain
$ nm -nm main
                 (undefined) external _foo (from libwrapper)

It looks like it would correspond reasonably well with sticking
everything within the one directly specified InputElement somehow.
Avoiding cycles seems like it might be the trickiest part.

Cheers.

Tim.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tmp.sh
Type: application/x-sh
Size: 327 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140710/3a4fd45f/attachment.sh>


More information about the llvm-dev mailing list