-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
macOS libc headers: add POSIX headers #7035
Conversation
These are both included by libcxx.
libcxx depends on it
libcxx depends on it
libcxx depends on it
libcxx depends on it
bcba23e
to
cd221b9
Compare
these new files are generated by recursively including: sysexits.h mach/mach.h sys/attr.h sys/mount.h crt_externs.h execinfo.h all of which are depended on by LLVM libraries.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! I'd suggest we wait with merging until @prime31 confirms it works for him :-)
On it right now. Will report back shortly. |
Do I have to pass any new flags through to the
Second:
|
If you want the system linker hack it's now an environment variable For the second one, looks like we need to add some more in https://github.com/ziglang/fetch-them-macos-headers |
Just to give you some context here @prime31 the point of these changes is that you would be able to cross compile your project targeting macOS from any other OS using only Zig. This is 1/2 of the puzzle, the other half is the linker issue, but that is a separate issue which I believe we are also close to solving. |
I figured as much for the headers. One issue I see with that though is that all the framework headers would all also need to be included. Switching to the system linker hack results in a new error:
|
Damn, that's what I was getting with zig-upaya as well and had no idea what the cause could have been... |
Indeed, but there doesn't seem to be any other way if we are to successfully cross-compile from any OS to macOS. |
Not quite the same but a similar error with
|
So, project 3 does build and run! And with the header update project 2 works as well. zig-upaya still does fail and I'll try project 4 next but I suspect it will fail because it needs Metal/MetalKit headers.
Is there a way to just force use the system headers or do we want to error out so that all the headers can be certain to be present? |
I think it's the latter. And then add more as we go (when we get more issues submitted). |
Hmm, the |
Another worrying thing is why are getting
|
I think we can at least include the libc headers, posix c headers, and darwin-specific system headers. Not all applications depend on frameworks. For example, the zig compiler itself does not need to link against any frameworks. I think we should treat frameworks as a separate issue, evaluating them on a case-by-case basis, look at the license of the header files, and how much MiB of data it would take to ship the headers, and whether we can cross-link against them, and then do the due diligence to fully support the framework. #1349 As far as this pull request is concerned I want to proceed carefully. I don't want to haphazardly add framework includes to fetch-them-macos-headers, but I also want to prevent projects such as the 3 we are looking at here from breaking. |
Yeah, I learned to just ignore stack traces. If you can get a nice, proper crash and the OS crash reporter pops up the stack trace in there is perfect. @andrewrk I just built and ran an app that access Metal/MetalKit successfully. Turns out all my projects add the framework include path returned by |
Just to recap, 3 out of 4 mixed C/C++/Zig projects now functional on macOS. I'm seeing if I can figure out where the last one has gone wrong from the outside, in case its fixable via build.zig or some other mechanism (if its a cache FileNotFound thats another thing of course). |
👍
Actually, you don't need to add those anymore since we automatically include |
OK, I think I found the reason for the unwrap trap. It seems that the last object file |
If I don't manually add them it seems I end up with |
Oh right, I guess you still need to add the framework search path just without the root, so |
@prime31 huh, when I comment out this bit in EDIT: it seems that we can only have one-to-one mapping in |
@kubkon confirmed that deleting the @andrewrk what kubkon is referring to is the following:
If always make the first executable in my projects duplicated as "run" so that |
@prime31 given that the problem with |
I don't see why not. It seems like a totally separate issue. Green light! |
See also https://github.com/kubkon/fetch-them-macos-headers/pull/1