Stub dylibs differ from "real" dylibs in that they lack any content in
their sections. What they do have are export tries and symbol tables,
which means we can still link against them. I am unclear how to
properly create these stub dylibs; XCode 11.3's lipo is able to create
stub dylibs, but those lack LC_ID_DYLIB load commands and are considered
invalid by most tooling. Newer versions of lipo aren't able to create
stub dylibs at all. However, recent SDKs in XCode still come with valid
stub dylibs, so it still seems worthwhile to support them. The YAML in
this diff's test was generated by taking a non-stub dylib and editing
the appropriate fields.
Details
Details
- Reviewers
smeenai - Group Reviewers
Restricted Project - Commits
- rG2e8e1bdb8939: [lld-macho] Support linking against stub dylibs
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Unit Tests
Event Timeline
Comment Actions
LGTM
lld/test/MachO/dylib-stub.yaml | ||
---|---|---|
25 | Any reason to prefer a universal binary with a single architecture to just a regular binary? |
lld/test/MachO/dylib-stub.yaml | ||
---|---|---|
25 | The stub dylibs bundled with XCode all seem to be contained within a universal binary (probably generated by some non-public version of lipo), so I figured this would be a more representative test case |
Any reason to prefer a universal binary with a single architecture to just a regular binary?