Skip to content

x/mobile: Unable to build xcframework with gomobile and Xcode 14 #53316

Closed
golang/mobile
#84
@darrarski

Description

@darrarski

What version of Go are you using (go version)?

$ go version
go version go1.18.3 darwin/arm64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE=""
GOARCH="arm64"
GOBIN=""
GOCACHE="/Users/darrarski/Library/Caches/go-build"
GOENV="/Users/darrarski/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/darrarski/.go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/darrarski/.go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/opt/homebrew/opt/go/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/opt/homebrew/opt/go/libexec/pkg/tool/darwin_arm64"
GOVCS=""
GOVERSION="go1.18.3"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/darrarski/Dev/repo/go.mod"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/bh/t75dvhh939lbvnsq6n60mgtr0000gn/T/go-build841782302=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I tried to build xcframework for iOS using Xcode 14 (14A5228q) developer tools with the following command:

$ gomobile bind -target ios gitlab.com/elixxir/client/bindings

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:

$ gomobile bind -target ios gitlab.com/elixxir/client/bindings
gomobile: ios/arm64: go build -buildmode=c-archive -o /var/folders/bh/t75dvhh939lbvnsq6n60mgtr0000gn/T/gomobile-work-1445876485/bindings-ios-arm64.a ./gobind failed: exit status 2
# runtime/cgo
cgo: C compiler "2022-06-09" not found: exec: "2022-06-09": executable file not found in $PATH

Activity

added this to the Unreleased milestone on Jun 9, 2022
cherrymui

cherrymui commented on Jun 9, 2022

@cherrymui
Member

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

added
NeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.
on Jun 9, 2022
changkun

changkun commented on Jun 10, 2022

@changkun
Member

I plan to upgrade to Xcode 14 soon so that it may be possible for me to take a look.

darrarski

darrarski commented on Jun 10, 2022

@darrarski
Author

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 :-)

darrarski

darrarski commented on Jun 10, 2022

@darrarski
Author

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 ;-)

cherrymui

cherrymui commented on Jun 10, 2022

@cherrymui
Member

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.

jakubgs

jakubgs commented on Sep 7, 2022

@jakubgs

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.

jakubgs

jakubgs commented on Sep 7, 2022

@jakubgs

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))

https://github.com/golang/mobile/blob/8578da9835fd365e78a6e63048c103b27a53a82c/cmd/gomobile/env.go#L434-L443

Which does indeed seem to call xcrun --find clang and accepts the output from cmd.CombinedOutput() indiscriminately.

jakubgs

jakubgs commented on Sep 7, 2022

@jakubgs

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.

jakubgs

jakubgs commented on Sep 7, 2022

@jakubgs

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.

added a commit that references this issue on Sep 8, 2022

21 remaining items

jakubgs

jakubgs commented on Oct 15, 2024

@jakubgs

The issue is clear. We had this problem, which is why we applied the patch which has fixed the issue:
https://github.com/status-im/status-mobile/blob/cfd30e0d2401bd61a519eba5d9f467b23120f721/nix/overlay.nix#L68-L71

You can see the error we got here:

 % 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

And the details in the issue and in the PR:

As we can see Apple is garbage and their tools spew nonsense into stdout. This has happened in the past and will happen again in the future. If you refuse to fix this then that's your problem. We use Nix so we can patch this ourselves without problems, but others might not be as lucky.

hajimehoshi

hajimehoshi commented on Oct 15, 2024

@hajimehoshi
Member

As we can see Apple is garbage and their tools spew nonsense into stdout.

As I said, I'm very skeptical about this assumption. I don't think the tool output the warning/debug messages to stdout.

jakubgs

jakubgs commented on Oct 15, 2024

@jakubgs

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.

hajimehoshi

hajimehoshi commented on Oct 15, 2024

@hajimehoshi
Member

It does.

But we cannot reproduce that, right?

jakubgs

jakubgs commented on Oct 15, 2024

@jakubgs

You can, just get an older Xcode version. And probably a matching OSX.

hajimehoshi

hajimehoshi commented on Oct 15, 2024

@hajimehoshi
Member

You can't deny it, you can just call me a liar. Have fun maintaining software this way.

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 CombinedOutput with Output. If you don't want, I'll make my CL to close this issue.

jakubgs

jakubgs commented on Oct 15, 2024

@jakubgs

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.

hajimehoshi

hajimehoshi commented on Oct 15, 2024

@hajimehoshi
Member

Sure, I'll do :-)

gopherbot

gopherbot commented on Oct 15, 2024

@gopherbot
Contributor

Change https://go.dev/cl/620315 mentions this issue: cmd/gomobile: use Output instead of CombinedOutput at envClang

added
NeedsFixThe path to resolution is known, but the work has not been done.
and removed
NeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.
on Oct 16, 2024
added a commit that references this issue on Oct 16, 2024
cc2e38a
added a commit that references this issue on Oct 16, 2024
7ff8300
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    NeedsFixThe path to resolution is known, but the work has not been done.mobileAndroid, iOS, and x/mobile

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

      Development

      Participants

      @hajimehoshi@johnmaguire@darrarski@dmitshur@jakubgs

      Issue actions

        x/mobile: Unable to build xcframework with gomobile and Xcode 14 · Issue #53316 · golang/go