-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[darwin aarch64 cgo] regression in 0.8.0-1366-gfc302f00a #10299
Comments
Oh and FYI, I'm not sure if you noticed but that linker is unable to find |
I did notice the warning, but it cross-compiled the executable successfully (i.e. produced a binary that A few follow-up questions:
|
This depends. By default, on macOS the linker is supposed to always link every shared object from the linker line. While it may not be strictly necessary since for instance you don't resolve any symbols in the said shared object, some runtime mechanism might depend on it, for instance you could use ObjC runtime to send a message as a string to poll the runtime address of the loaded Foundation framework. In this case, if you didn't link any symbols from Foundation and your linker stripped this dylib from the binary (treating it as unused), ObjC will return address This situation reminds of this in that while this particular Hello World example didn't require the CoreFoundation framework, some inner Go mechanism might which will manifest is a really nasty and difficult to track runtime exception. The question now is: should zig warn the user or perhaps throw an error instead? Initially I assumed the former is enough, but if zig is used as a drop-in C/C++ compiler replacement and is used inside another build tool (like More on this topic: #10192
That's an interesting one, and I don't really have an answer to that. Some folks have packaged a sysroot for a version of macOS already, for instance https://github.com/hexops/sdk-macos-11.3. Legal implications - I have no clue, however, I'd recommend packaging only
We use the sysroot in a few places mainly when building natively (we then pull the libc headers from there together with framework stubs), but it's also required when linking in frameworks on macOS (or targeting macOS). When linking in dylibs we do a recursive linking of any dylib that the original dylib re-exported, and to resolve that we often require a sysroot to prepend to the path. Otherwise the resolution might fail. |
Let me try to re-phrase to see if I understood this correctly: Foundation needs to be linked in a Mach-O binary; but, if SDK is not specified, zld will set it's address to
If my re-phrasing above is correct, then I definitely agree we should be more vocal:
In our case,
To be clear: is this required for x86_64 too, not only aarch64? I am clarifying, because compiling x86_64 does not produce Only the
For the record, our use case (bazel-zig-cc) is always "cross-compilation" mode, that's how we get hermetic builds. So our builds don't have to rely on anything in the system (and, by extension, produced binaries are the same, regardless where they are compiled). |
Hey @motiejus it looks like I'm seeing some similar messages for |
Yes, sounds about right. I guess the SDK is necessary for darwin-any then. |
@uhthomas so here's the rule of thumb to remember and follow:
|
Not quite. When you specify #include <assert.h>
#include <objc/runtime.h>
int main() {
assert(objc_getClass("NSObject") > 0);
assert(objc_getClass("NSApplication") > 0);
} If you don't link
But that's the thing. It's not always required. For example, if you don't link in any frameworks, Zig's got you covered as it includes
In that case, we might make it a hard error if you want to link a framework and zig cannot find it. I'll need to check what Apple's
No, the behaviour should be common on any architecture targeting macOS - we should only look for the SDK if compiling natively. Lemme check quickly locally on my Intel MBP why there's no warning.
|
@motiejus I just checked and Go doesn't link in the framework on x86_64 macOS, but does on aarch64 macOS. Fancy that! EDIT:
I don't use Go nor know enough about it, but it might be worth checking with Go devs where the difference comes from between the two targets. |
I see thank you. Apologies if you're having to repeat yourself. Do you have any advice on where to get a sysroot when targeting macOS? It sounds to me like there's no standard way of doing this. |
No problem at all. So if you're on macOS, there are two ways: 1) install CLT (I bet you already did), 2) install Xcode. Either way, you can then use the
If you're on a non-macOS host, then you will need to supply the sysroot yourself. Something like this for instance https://github.com/hexops/sdk-macos-11.3. Finally, note that if you don't require to link against frameworks, you don't need to specify the sysroot as Zig ships both |
It looks like Apple is putting more effort into open source contribution. I wonder if it's available as part of their releases somewhere. https://opensource.apple.com/releases/ |
Yes if you pass |
Since it was mentioned, I should note there's a much nicer Zig file to consume these: https://github.com/hexops/mach/blob/main/glfw/system_sdk.zig It lets you just write By default it also won't set the |
If `-framework` is requested, but not found, the linker will err instead of creating a strange executable. ziglang#10299 (comment) Refs ziglang#9542 Refs ziglang#10299 Refs ziglang#10158
It is possible to download the SDKs directly from Apple:
I found them by searching for To extract them: |
Zig Version
0.8.0-1921-g83a668195
Steps to Reproduce
Identical to #10297, but substitute:
x86_64
withaarch64
.amd64
witharm64
.Step-by-step:
hello.go
~/test
~/zcc
Bisect Result
fc302f0 is the first bad commit, which doesn't revert cleanly.
Expected Behavior
~/test
should produce a working darwin aarch64 executable.Actual Behavior
Running
~/test
on master fails to produce an executable:cc @kubkon
The text was updated successfully, but these errors were encountered: