Skip to content
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

zig cc -target aarch64-macos-gnu fails with FrameworkNotFound when used with cgo #10513

Closed
charleskorn opened this issue Jan 5, 2022 · 8 comments
Labels
os-macos question No questions on the issue tracker, please.

Comments

@charleskorn
Copy link

Zig Version

0.9.0

Steps to Reproduce

I've created a repository https://github.com/charleskorn/zig-cgo-libs that contains a sample project, build script (./build.sh) and GitHub Actions workflow (sample build) that demonstrates the problem.

To reproduce this for yourself, clone the repository and run ./build.sh.

The tl;dr appears to be: when using Zig as a C compiler for Golang's cgo, Zig fails to find the CoreFoundation framework if -target is specified explicitly. ie. zig cc -target aarch64-macos-gnu ... fails, but if I compile on my M1 Mac with no -target, the build succeeds.

I've passed --sysroot with the path provided by xcrun --show-sdk-path, as suggested in #10299 (comment).

Expected Behavior

Build succeeds.

Actual Behavior

Build fails with a FrameworkNotFound error, and a warning that the framework could not be found (and that there are no framework search paths):

warning(link): framework not found for '-framework CoreFoundation'
warning(link): Framework search paths:
error: FrameworkNotFound

I can see zig is being invoked with the expected arguments, for example:

zig cc -target aarch64-macos-gnu --sysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -I /opt/homebrew/Cellar/go/1.17.5/libexec/src/runtime/cgo -fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/7t/_rsz39554vvgvq2t6b4ztktc0000gn/T/go-build3089540943/b017=/tmp/go-build -gno-record-gcc-switches -fno-common -o $WORK/b017/_cgo_.o $WORK/b017/_cgo_main.o $WORK/b017/_x001.o $WORK/b017/_x002.o $WORK/b017/_x003.o $WORK/b017/_x004.o $WORK/b017/_x005.o $WORK/b017/_x006.o $WORK/b017/_x007.o $WORK/b017/_x008.o $WORK/b017/_x009.o -g -O2 -framework CoreFoundation

I see the same behaviour on both M1 and Intel hosts.

@charleskorn charleskorn added the bug Observed behavior contradicts documented or intended behavior label Jan 5, 2022
@kubkon
Copy link
Member

kubkon commented Jan 5, 2022

You need to manually specify include, library and framework search dirs for this to work. In cross-compilation mode, which Zig enters when you explicitly specify the target, no search paths are populated since we don't know where to expect them. Passing the sysroot is one thing, the next should be specifying -I/usr/include, -F/System/Library/Frameworks and -L/usr/lib. Have a look at github.com/kubkon/zig-ios-example to see how this can be done in build.zig. For CGO, I guess you will need to either pass those manually, or put them in some CGO flags, perhaps?

@charleskorn
Copy link
Author

Thanks for the tip @kubkon - I had to use -I<sysroot>/usr/include, -F<sysroot>/System/Library/Frameworks and -L<sysroot>/usr/lib, but that was enough to get things working.

Are there any other settings set by default when not specifying -target that I should be using? I also had to add -Wno-expansion-to-defined -Wno-availability -Wno-nullability-completeness to suppress a bunch of warnings that aren't generated when not specifying -target.

@andrewrk andrewrk added question No questions on the issue tracker, please. and removed bug Observed behavior contradicts documented or intended behavior labels Feb 2, 2022
@andrewrk
Copy link
Member

andrewrk commented Feb 2, 2022

Duplicate of #1349 and #10660.

@charleskorn
Copy link
Author

@andrewrk it looks like there are two issues here:

Do you want me to open a separate issue for the second part?

@andrewrk
Copy link
Member

andrewrk commented Feb 4, 2022

Yes please 👍

@kubkon
Copy link
Member

kubkon commented Feb 4, 2022

@andrewrk it looks like there are two issues here:

Do you want me to open a separate issue for the second part?

Is it by any chance related to and fixed by #10568? If so, this fix should land in 0.9.1 I believe - cc'ing @andrewrk to confirm he cherry-picked the commit from the linked PR.

@andrewrk
Copy link
Member

andrewrk commented Feb 4, 2022

Confirmed, it's in the 0.9.x branch as 3542dca.

@charleskorn
Copy link
Author

Yes please 👍

Done: #10790

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
os-macos question No questions on the issue tracker, please.
Projects
None yet
Development

No branches or pull requests

3 participants