Open darrarski opened 2 years ago
cgo: C compiler "2022-06-09"
I think gomobile picks up the C compiler from running xcrun --find clang
, and that command on darwin/arm64 can sometimes contains bogus logging output starting with the date and time. That probably confuses gomobile.
Could you try running that command again, maybe twice?
gomobile should probably be more resilient on that. Maybe it should only use stdout of xcrun
, not stderr
. cc @hyangah
@golang/ios
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 xcrun --find clang
, which gives the following output:
with Xcode 13.4.1 (13F100):
$ xcrun --find clang
/Applications/Xcode-13.4.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
with Xcode 14 (14A5228q):
$ xcrun --find clang
/Applications/Xcode-14.0.0-Beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
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 plan to upgrade to Xcode 14 soon so that it may be possible for me to take a look.
I'm afraid you'll need to go back in time to reproduce ;-)
On my mac M1 machine, it sometimes print messages like
2022-06-07 22:25:25.471 xcodebuild[8405:27734] 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-06-07 22:25:25.471 xcodebuild[8405:27734] 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
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:
% xcrun --find clang
2022-09-07 14:27:45.757 xcodebuild[6265:9851879] 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:27:45.757 xcodebuild[6265:9851879] 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:27:45.813 xcodebuild[6265:9851879] XType: com.apple.fonts is not accessible.
2022-09-07 14:27:45.813 xcodebuild[6265:9851879] XType: XTFontStaticRegistry is enabled.
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
These warnings appear to be included in stdout
instead of stderr
, and hence they affect how the path is parsed.
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 envClang()
function:
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 xcrun --find clang
and accepts the output from cmd.CombinedOutput()
indiscriminately.
Based on my tests this appears to only happen on the first try:
Last login: Wed Sep 7 09:14:57 2022 from 12.34.56.67
% 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
% xcrun --find clang
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
% xcrun --find clang
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
% xcrun --find clang
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
After host reboot it resets and those log messages show up again.
According to this discussion: https://developer.apple.com/forums/thread/703233 The fix is:
Remove CommandLineTools
sudo rm -rf /Library/Developer/CommandLineTools
Reinstall CommandLineTools
xcode-select --install
Select CommandLineTools
sudo xcode-select -s /Library/Developer/CommandLineTools
But I tried reinstalling Command Line Tools or installing newer than 13.3.1
- in my case 13.4
- and the message is still there.
Honestly some input validation could be added to envClang
.
Small update from my side:
Not sure what changed, but now I'm able to run gomobile bind
with the following configuration:
No more "cgo: C compiler" errors occurs when running gomobile bind
. It binds successfully, however, the produced xcframework is not usable. When trying to build iOS or macOS application that uses the framework, I get this error:
Undefined symbols for architecture arm64:
"_objc_msgSend$initWithObject:", referenced from:
-[RefTracker assignRefnumAndIncRefcount:] in Bindings(000007.o)
"_objc_msgSend$setObject:forKeyedSubscript:", referenced from:
-[RefTracker assignRefnumAndIncRefcount:] in Bindings(000007.o)
"_objc_msgSend$intValue", referenced from:
...
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 gomobile bing
failed to run). I created a new issue for it: #55028
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 gomobile bind
without any issues on the following setup:
gomobile
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:
@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!
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: