zig ld: link Obj-C, link frameworks, improve linker's implementation #9229
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Move the logic into default-init structs part of constructors in `SegmentCommand` struct in `commands.zig` module.
After giving it more thought, it doesn't make sense to separate the two structurally. Instead, there should be two constructors for a Dylib struct: one from binary file, and the other from a stub file. This cleans up a lot of code and opens the way for recursive parsing of re-exports from a dylib which are a hard requirement for native feel when linking frameworks.
when parsing the umbrella lib
after `LC_LOAD_DYLIB` commands to match ld64 and make the binaries compatible with Apple tools.
kubkon
added a commit
to kubkon/pacman.zig
that referenced
this pull request
Jun 24, 2021
which include: * ast fixes * `extern enum(i32)` is now `enum(i32)` * there is no need for `ZIG_SYSTEM_LINKER_HACK` on macOS The last change depends on ziglang/zig#9229
|
Thanks @kubkon, I don't mind re-basing. |
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
General gist of the PR
.msources and link them correctly withzig ldIn more detail
This now works on macOS without the system linker hack (cc @floooh, @prime31, @mikdusan):
and produces a functional binary with all frameworks and dylibs (here,
libobjc.dylib,Foundation.dylib,CoreFoundation.dyliband of courselibSystem.dylib) autoresolved - the linker when resolving dylibs from tbd stubs now automatically descends the re-exported tree and looks for dependent libraries meaning it's enough to just link with the top framework, e.g., Foundation. This effectively mimics the behaviour ofld64makingzig lda true linker replacement for the end-user.Scanning of dependent libs is currently missing for binary dylibs (as opposed to tbd stubs), and the linker doesn't yet track the visited dylibs meaning it may visit a linked dylib more than once if it is referenced in multiple linked frameworks. Oh, and we don't detect cycles which we probably should for malformed dynamic libraries.
I have also exposed
zig ccto Obj-C sources, i.e., it accepts.mfiles; however, given that @redj started working on a more general exposition in #9029, I'm happy to reverse the change, or whatever is needed. Exposing this option allowed me to test linking Obj-C with Zig in a systematic and simple manner hence why it's included in this PR.