ARM64(M1 Mac) - bad CPU type in executable cgo

[bdkiran]

Go version

go version go1.21.5 darwin/arm64

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

GO111MODULE=''
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/burakkiran/Library/Caches/go-build'
GOENV='/Users/burakkiran/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/burakkiran/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/burakkiran/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.21.5'
GCCGO='gccgo'
AR='ar'
CC='clang'
CXX='clang++'
CGO_ENABLED='1'
GOMOD='/Users/burakkiran/project/providers/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/var/folders/66/m0ltsv192tl3tbf3cq4t2lgh0000gn/T/go-build556361885=/tmp/go-build -gno-record-gcc-switches -fno-common'

What did you do?

Hi, I have just set up my M1 mac and am having trouble running a go project that I had originally built using an Intel based mac

1. I downloaded the latest version of Go and Pulled down the repo

2. Project Set up and Installed Dependencies

go get .

3. I ran both commands:

go run .

go build

More info

This project leverages Sqlite so I understand where the cgo dependency is needed. Am I missing a step in my go installation to link to the correct C compiler?

Dependencies that the project is pulling in from go.mod:

require (
        github.com/mattn/go-sqlite3 v1.14.17
	github.com/gorilla/sessions v1.1.1
	github.com/markbates/goth v1.78.0
	golang.org/x/crypto v0.14.0
)

What did you expect to see?

Program executes, in this instance a web server.

What did you see instead?

Stack trace

# runtime/cgo
cgo: exec clang: fork/exec /usr/local/opt/llvm/bin/clang: bad CPU type in executable# runtime/cgo

Related Issues:
Somewhat similar, different stack trace:
#45772

Same error building docker compose which is a go based project:
docker/for-mac#6232
Solution seemed to be:

softwareupdate --install-rosetta

But is x86 -> arm64 translation needed for such a simple project/build?

[mauri870]

Cgo is supported on darwin/arm64, what is the output of clang --version? It does appear that your clang is x86-64. Also, can you share a trimmed down reproducer and the commands used to build so we can try to reproduce the issue? Thanks.

[bdkiran]

Clang version

% clang --version
Apple clang version 14.0.3 (clang-1403.0.22.14.1)
Target: arm64-apple-darwin22.3.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

Reproduced Output

When developing I use the go run command. This worked on the x86 mac with no problems

% go run .
# runtime/cgo
cgo: exec clang: fork/exec /usr/local/opt/llvm/bin/clang: bad CPU type in executable

go build, no flags to build

burakkiran@Buraks-MacBook-Pro providers % go build .
# runtime/cgo
cgo: exec clang: fork/exec /usr/local/opt/llvm/bin/clang: bad CPU type in executable

[bdkiran]

I think I solved the problem:
Since I used a time machine backup, x86 llvm was installed onto the m1 computer in /usr/local/opt/llvm.
Also my .zshrc file had the following line:
export PATH="/usr/local/opt/llvm/bin:$PATH"

After removing that line from the .zshrc file the program built successfully. I assume it was able to use the arm64 version of clang that I showed above.

My question is how does cgo/go choose which clang version to use if multiple are installed? Is it the one that is exported in the shell that is automatically selects? This context may be important for others that run into the same problem

[mauri870]

That appears to be an issue with your PATH, you had multiple versions of clang installed and probably Go was picking the wrong one. On Go's side it uses the compiler you have exported in CC, but that might not be the one you want if you have multiple versions in your path. You can always use the absolute path to CC if you want more control in this case. I'm glad you fixed it.

For questions please refer to https://github.com/golang/go/wiki/Questions