cmd/go: ld: building for macOS, but linking in object file built for iOS

[bradfitz]

Go 1.19.4

When building our application, a few of us occasionally get the error:

/Users/bradfitz/.cache/tailscale-go/pkg/tool/darwin_arm64/link: running gcc failed: exit status 1
ld: building for macOS, but linking in object file built for iOS, file '/var/folders/0f/7sz95dc94nj46b6yz8p_fqd40000gn/T/go-link-3835913802/000004.o' for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

And the only way to recover is to do a go clean -cache and build again.

We haven't figured out more than that, yet. And we don't have an on-demand repro.

Just filing this now in case anybody has any ideas.

Like, maybe piece of the environment is missing from the cache signature? Maybe an empty file is being created that's being interpreted as iOS instead of macOS?

But that error message is not a Go thing at all. I see tons of Google results for other languages. But maybe cmd/go can detect whatever broken state its input is in and ignore that input file and rebuild it instead? Totally guessing.

/cc @ianlancetaylor who likes linkers :)

[spatialbits]

Ran into this on Friday after upgrading from 1.19.1 to 1.19.4.

[ianlancetaylor]

It sounds like once this problem occurs, it is repeatable. If so, then when it happens again, run with -ldflags=-tmpdir=/my/private/tmpdir and take a look at the failing file.

[simbadMarino]

Hello guys, I'm having a similar issue while trying to build my binary into Xcode 15, comparing output from otool -lv between an old binary and a new one using either go 1.20/21/22 I notice a big difference : I' ve tried cleaning cache, compiling my go library using legacy clang and nothing seems to work... I hope anyone can support , I'm attaching the output comparison here.

Looks like the macOS platform is getting in even when I compile for iOS....

My make as follows:

ios-arm64:
CGO_ENABLED=1
GOOS=ios
GOARCH=arm64
SDK=iphoneos
SDK_PATH=xcrun --sdk iphoneos --show-sdk-path
CARCH="arm64"
CC=$(PWD)/clangwrap.sh
CGO_CFLAGS="-fembed-bitcode"
go build -v -buildmode=c-archive -ldflags="-s -w" -gcflags=all="-l -B" -tags ios -o $(IOS_OUT)/btfs.a .

[cherrymui]

@simbadMarino could you show exactly what commands you run, including the otool command. What objects are you inspecting in otool? They are probably C objects, not Go objects. Could you try passing the -x flag to go build and paste the output? That would include the commands the C objects are compiled.

[simbadMarino]

Sure, thanks for the help!! and quick response :) @cherrymui

I'm attaching the output with -x flag.
outputCompileBTFS.zip

I'm inspecting the binary .an objects (c-archives) . The command I'm using to inspect them is: otool -lv btfs.a | grep -A5 LC_BUILD

[cherrymui]

What is the content of your clangwrap.sh?

# runtime/cgo
clang: error: unable to execute command: Segmentation fault: 11
clang: error: linker command failed due to signal (use -v to see invocation)

In your output I see C compilation failures above, which looks like the C toolchain seg faulted, which seems like a bug in the C toolchain.

Also, please paste output as plain text, no color or rich format. Thanks.

[simbadMarino]

@cherrymui My clangwrap:

#!/bin/sh
# This uses the latest available iOS SDK, which is recommended.
# To select a specific SDK, run 'xcodebuild -showsdks'
# to see the available SDKs and replace iphoneos with one of them.
if [ "$GOARCH" == "arm64" ]; then
	SDK=iphoneos
	PLATFORM=ios
	CLANGARCH="arm64"
else
	SDK=iphonesimulator
	PLATFORM=ios-simulator
	CLANGARCH="x86_64"
fi

SDK_PATH=`xcrun --sdk $SDK --show-sdk-path`
export IPHONEOS_DEPLOYMENT_TARGET=5.1
# cmd/cgo doesn't support llvm-gcc-4.2, so we have to use clang.
CLANG=`xcrun --sdk $SDK --find clang`

exec "$CLANG" -arch $CLANGARCH -isysroot "$SDK_PATH" -m${PLATFORM}-version-min=12.0 "$@"

Adding the file again as plain text
outputbuild_btfs.txt

I haven't noticed any segmentation faults before without adding the -x flag! :/

[cherrymui]

Without the -x flag, the seg fault is probably still there but not printed to users. Either way, seg fault in C toolchain is clearly unexpected. There is probably a bug in the C toolchain or the SDK. Maybe you could try setting CGO_CFLAGS=-v CGO_LDFLAGS=-v and see if it prints anything useful. Also maybe try a different version of the C toolchain or SDK.

[simbadMarino]

I noticed that by removing the CGO_CFLAGS="-fembed-bitcode" \ line in the make file I get rid of the segmentation faults, but still get the linking errors while building in Xcode :/.

Good news is that after trying the verbose option for CGO as you suggested Im getting the following:

Linking error is pointing to a specific library(go-libutp), I'll dig into it and report how it goes :) Thanks again for all the support @cherrymui !

[cherrymui]

Okay, https://github.com/anacrolix/go-libutp has C++ files, which may be compiled targeting macOS instead of iOS. Try setting the CXX environment variable to a C++ compiler targeting iOS. You may need a clang++ wrapper script similar to clangwrap.

[simbadMarino]

You were right! by adding the CXX flag pointing to clang fixed my issue!, additional to this starting from go 1.20 if you are linking a c-archive binary with net dependency you need to add CGO_LDFLAGS=-lresolv \ flag for CGO as per release notes:

I case someone else need this below you can see how I ended up configuring my make and Xcode :

make:

ios-arm64:
	CGO_ENABLED=1 \
	GOOS=ios \
	GOARCH=arm64 \
	CC=$(PWD)/clangwrap.sh \
	CXX=$(PWD)/clangwrap.sh \
	CGO_CFLAGS="-fembed-bitcode" \
	CGO_LDFLAGS=-lresolv \
	go build -v -buildmode=c-archive -ldflags="-s -w" -gcflags=all="-l -B" -tags ios -o $(IOS_OUT)/btfs.a .

Xcode Build settings (add -lresolv flag under Other linker flags):

Thanks a lot for the support @cherrymui ! , without your advice I would be still clueless 👍