From what I can tell, it's essentially identical to
-sub_library, but it doesn't match files ending in ".dylib".
Details
- Reviewers
thakis - Group Reviewers
Restricted Project - Commits
- rG8a5e06882336: [lld-macho] Support -sub_umbrella
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
lgtm. Below is what I checked:
Doesn't sub_umbrella cause a different load command? (LC_SUB_UMBRELLA, sub_umbrella_command -- which admittedly has the same in-memory repr as sub_library_command, but the cmd id is different)
% touch foo.cc % clang foo.cc -c % clang -shared -o foo.dylib foo.o % clang -shared -o bar.dylib foo.o -sub_umbrella foo.dylib foo.dylib % otool -l bar.dylib | grep -C5 foo.dylib cmdsize 16 version 0.0 Load command 9 cmd LC_REEXPORT_DYLIB cmdsize 40 name foo.dylib (offset 24) time stamp 2 Wed Dec 31 19:00:02 1969 current version 0.0.0 compatibility version 0.0.0 Load command 10 cmd LC_LOAD_DYLIB
…no, it's just a LC_REEXPORT_DYLIB. Looking through ld64, that seems to match the handling there (but looking for it made me find -debug_snapshot / -snapshot_dir which I didn't know before. I guess that's like our --reproduce? If so, that'd be exciting! I'll add support for that spelling of --reproduce then, similar to how the coff port has both /reproduce: and /linkrepro:, the latter to match link.exe). So this looks correct.
There's a comment in ld64 that says
// target OS does not support LC_REEXPORT_DYLIB, so use old complicated load commands
So I guess that's what LC_SUB_{UMBRELLA, LIBRARY} are.