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

[cmacknz]

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:

• feat: build arm64 Docker image for amd64/arm64 (backport #201) #208
• feat: build darwin amd64/arm64 Docker images (backport #200) #207
• [1.17](backport #209) fix: set default values for architectures #210
• [automation] Update go release version 1.17.11 #213

[cmacknz]

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

[kuisathaverat]

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)