search

elastic / golang-crossbuild

Apache License 2.0
3 stars 32 forks source link

Beats packaging fails when cross-compiling to Darwin after upgrade from Go 1.17.10 to Go 1.17.11 image #217

Open cmacknz opened 2 years ago

cmacknz commented 2 years ago

To reproduce the issue in https://github.com/elastic/beats:

cd auditbeat
CGO_ENABLED=1 PLATFORMS="darwin/amd64" DEV=1 MAGEFILE_VERBOSE=true mage package

The command will fail with the error:

[2022-07-08T12:08:43.110Z] Status: Downloaded newer image for docker.elastic.co/beats-dev/golang-crossbuild:1.17.11-darwin-arm64-debian10
[2022-07-08T12:08:49.693Z] >> Building using: cmd='build/mage-linux-amd64 golangCrossBuild', env=[CC=oa64-clang, CXX=oa64-clang++, GOARCH=arm64, GOARM=, GOOS=darwin, PLATFORM_ID=darwin-arm64]
[2022-07-08T12:11:14.379Z] # github.com/elastic/beats/v7/auditbeat
[2022-07-08T12:11:14.379Z] /usr/local/go/pkg/tool/linux_amd64/link: /usr/local/go/pkg/tool/linux_amd64/link: running dsymutil failed: exit status 1
[2022-07-08T12:11:14.379Z] osxcross: error: xcrun: cannot find 'dsymutil' executable
[2022-07-08T12:11:14.379Z] 
[2022-07-08T12:11:14.379Z] Error: running "go build -o build/golang-crossbuild/auditbeat-darwin-amd64 -buildmode pie -gcflags "all=-N -l" -ldflags -X github.com/elastic/beats/v7/libbeat/version.buildTime=2022-07-08T12:07:37Z -X github.com/elastic/beats/v7/libbeat/version.commit=ea6635f5bfb8586ff63b91e14995084fd56da2e3" failed with exit code 2
[2022-07-08T12:11:14.379Z] Error: failed building for darwin/amd64: exit status 2
[2022-07-08T12:11:14.379Z] failed building for darwin/amd64: exit status 2

Downgrading to the Go 1.17.10 crossbuild image or setting DEV=0 fixes the issue.

There were multiple changes merged to the Go 1.17 branch between the Go 1.17.10 and Go 1.17.11 version bumps (https://github.com/elastic/golang-crossbuild/commits/1.17) that could be responsible for this:

cmacknz commented 2 years ago

This doesn't seem to affect builds with PLATFORMS="darwin/arm64", at least not when building on an M1 machine.

kuisathaverat commented 2 years ago

at least not when building on an M1 machine.

Running on arm64 Docker chooses the Docker image build for arm64, it is different than the one run on an amd64-based machine, all the tools compilers, and so on are built for a different architecture so it is not a surprise that behaves in a different way.

CGO_ENABLED=1 in a cross-compile environment could behave differently than in a native build environment, for me it is difficult to justify the use of CGO_ENABLED (see https://dave.cheney.net/tag/cgo)