-
Notifications
You must be signed in to change notification settings - Fork 17.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
x/mobile: Unable to build xcframework with gomobile and Xcode 14 #53316
Comments
I think gomobile picks up the C compiler from running Could you try running that command again, maybe twice? gomobile should probably be more resilient on that. Maybe it should only use stdout of |
I plan to upgrade to Xcode 14 soon so that it may be possible for me to take a look. |
I tried to run the command several times yesterday, but the result was always the same. I'm unfamiliar with golang, but the error message "exec: 2022-06-09 not found" seemed suspicious. I thought it could be some kind of parsing issue. I'm not sure if the problem is caused by parsing the result of with Xcode 13.4.1 (13F100):
with Xcode 14 (14A5228q):
However, I rerun the command today, and... it works! Still, I believe there is a bug hiding somewhere, as the problem was probably caused by the given date when the command was run (2022-06-09). Thankfully today (2022-06-10) it works fine :-) |
I'm afraid you'll need to go back in time to reproduce ;-) |
On my mac M1 machine, it sometimes print messages like
It doesn't always print that. In my experience it is more likely to print if it is the first time to use such commands in a while. And the second and subsequent runs just behave normally, without the extra output. Maybe it will print if you restart the machine and run that command immediately. |
I have also experienced this issue with the following messages:
These warnings appear to be included in I have currently no idea how to fix those warnings. A proper fix would probably involve parsing and matching all lines with a regex. |
The issue appears to be coming from func envClang(sdkName string) (clang, cflags string, err error) {
if buildN {
return sdkName + "-clang", "-isysroot " + sdkName, nil
}
cmd := exec.Command("xcrun", "--sdk", sdkName, "--find", "clang")
out, err := cmd.CombinedOutput()
if err != nil {
return "", "", fmt.Errorf("xcrun --find: %v\n%s", err, out)
}
clang = strings.TrimSpace(string(out)) Which does indeed seem to call |
Based on my tests this appears to only happen on the first try:
After host reboot it resets and those log messages show up again. |
According to this discussion: https://developer.apple.com/forums/thread/703233
But I tried reinstalling Command Line Tools or installing newer than Honestly some input validation could be added to |
Currently some installations of Xcode and Command Line Tools cause warnings about missing extensions which break parsing of paths returned from `xcrun` that `gomobile` depends on resulting in errors like this: ``` cgo: C compiler "2022-09-07" not found: exec: "2022-09-07": executable file not found in $PATH ``` This is caused by these warnings returned on `stdout` by `xcrun`: ``` > xcrun --find clang 2022-09-07 14:50:13.907 xcodebuild[69942:386823822] Requested but did not find extension point with identifier Xcode.IDEKit.ExtensionSentinelHostApplications for extension Xcode.DebuggerFoundation.AppExtensionHosts.watchOS of plug-in com.apple.dt.IDEWatchSupportCore 2022-09-07 14:50:13.908 xcodebuild[69942:386823822] Requested but did not find extension point with identifier Xcode.IDEKit.ExtensionPointIdentifierToBundleIdentifier for extension Xcode.DebuggerFoundation.AppExtensionToBundleIdentifierMap.watchOS of plug-in com.apple.dt.IDEWatchSupportCore 2022-09-07 14:50:14.041 xcodebuild[69942:386823822] XType: com.apple.fonts is not accessible. 2022-09-07 14:50:14.041 xcodebuild[69942:386823822] XType: XTFontStaticRegistry is enabled. /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang ``` Resulting in `gomobile` interpreting the date `2022-09-07` as Clang compiler. Resolves: golang/go#53316 Signed-off-by: Jakub Sokołowski <[email protected]>
Small update from my side: Not sure what changed, but now I'm able to run
No more "cgo: C compiler" errors occurs when running
I truncated it because it just lists all functions and methods that gomobile exposes from go to Objective-C. When creating the same xcframework with Xcode 13.4.1, everything works fine, without any issues. UPDATE: Because the above problem is probably not related to the original one (with UPDATE: There was something messed up with my local environment. I reinstalled golang and can't reproduce the issue anymore. Sorry for the confusion. I can now use
Not sure what resolved the original issue I reported here, but I think we can now close it. |
@darrarski please do not close this, this is a valid issue I'm fixing in: |
Oh, OK, sorry for that. Will keep an eye on the progress, but like I said - it works now for me with latest Xcode and gomobile. Thanks a lot for all your precious time and effort! |
We're hitting a variation of this issue as well:
We were able to stop the warnings in the meantime with:
We believe these environment variables are set by Xcode. The warnings are emitted when running gomobile with the environment variables set, and no flags:
This comes from xcrun:
The fix in golang/mobile#84 looks like it would solve our problem. |
John found an issue in gomobile that seems to be the culprit of one of these issues: golang/go#53316 (comment)
I don' think anyone cares. I've submitted a fix for this 2 years ago and nobody has even reviewed it: We just apply a patch to this tool at build time through Nix, because this will probably never get merged: |
How did you check this? What was the result of |
In my own testing, xcrun appears to print warnings to stderr, yet they interfere with the gomobile build anyway:
|
I cannot distinguish whether |
@hajimehoshi
Do you understand? |
I do not have this issue:
I have a related issue, per my original comment #53316 (comment) which is also fixed by the linked PR. |
@johnmaguire So, as you already said, the warning at #53316 (comment) was not output, which means you have not reproduced the case.
By the way, I cannot reproduce the issue either, so I cannot test this. |
https://go-review.googlesource.com/c/mobile/+/432657/comment/571d2b9a_3519aa82/ My intuition is that just replacing |
@hajimehoshi I apologize - I did not read the linked PR (only the title) and I understand the confusion now. I agree that replacing @jakubgs will need to test the command you suggested, as I cannot reproduce the messages he is seeing. |
I think that depends on Xcode version and other factors.
You cannot expect Apple to be consistent. My fix is still necessary I think, as Apple is a garbage company. |
@jakubgs So would it be possible to reproduce the debug message |
As I said, it's xcode version dependent. |
So we can no longer confirm the debug message was really output to stdout, not stderr. I'm very skeptical about this (the debug message was output to stdout). We should go with replacing |
The issue is clear. We had this problem, which is why we applied the patch which has fixed the issue: You can see the error we got here:
And the details in the issue and in the PR:
As we can see Apple is garbage and their tools spew nonsense into |
As I said, I'm very skeptical about this assumption. I don't think the tool output the warning/debug messages to stdout. |
It does. We fixed it with the patch I've linked. You can't deny it, you can just call me a liar. Have fun maintaining software this way. |
But we cannot reproduce that, right? |
You can, just get an older Xcode version. And probably a matching OSX. |
I'm just pointing out that you might be misunderstanding. From the comments #53316 (comment) and #53316 (comment), the stdout and stderr seemed to be mixed so we cannot say the debug message was really output to stdout. I'm fine to help you if we go with replacing |
I have no interest nor time to reproduce this for you. As I said, we patched it thanks to Nix being amazing. The issue is real and will show up again, whether with older or newer combinations of Xcode and OSX. I would not close it if I were you, but you do you. |
Sure, I'll do :-) |
Change https://go.dev/cl/620315 mentions this issue: |
It dosen't make sense to parse stdout and stderr to get a necessary information like clang command. Actually envClang sometimes didn't work correctly due to this. Fixes golang/go#53316 Change-Id: Ia2c518c44c0003b4f9b50dba85fb971c2ef4340d Reviewed-on: https://go-review.googlesource.com/c/mobile/+/620315 Reviewed-by: Dmitri Shuralyov <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> Reviewed-by: Michael Knyszek <[email protected]>
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
I tried to build xcframework for iOS using Xcode 14 (14A5228q) developer tools with the following command:
What did you expect to see?
I expected the command to create xcframework. It works when I switch to Xcode 13.4.1 (13F100) developer tools.
What did you see instead?
When using Xcode 14 (14A5228q) developer tools, the command fails with the following error:
The text was updated successfully, but these errors were encountered: