[Bug] CGO_ENABLED on macos amd64 is not correct

[timandy]

Description:
A clear and concise description of what the bug is.

Action version:
actions/setup-go@v5

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Tools version:
go 1.18
go 1.19

Repro steps:

      - name: Set up Go
        uses: actions/setup-go@v5
        with:
          go-version: ${{ matrix.go }}

      # darwin
      - name: 'Test on [darwin] arch [amd64]'
        if: ${{ matrix.os == 'darwin' && contains(fromJson('["amd64"]'), matrix.arch) }}
        env:
          GOOS: ${{ matrix.os }}
          GOARCH: ${{ matrix.arch }}
        run: |
          echo ${CGO_ENABLED}   //print empty
          go env CGO_ENABLED //print 0 - should be 1

Expected behavior:
go env CGO_ENABLED //should be 1

Actual behavior:
printed 0, On windows and linux print 1

mac
https://github.com/timandy/routine/actions/runs/8965563348/job/24619393933#step:4:11

linux
https://github.com/timandy/routine/actions/runs/8965563348/job/24619398442#step:6:11

[aparnajyothi-y]

Hello @timandy, zthank you for creating this issue and we will look into it :)

[matthewhughes934]

I suspect this might be something to do with those versions of Go being built differently/in such a way that they don't support cross compilation. Possibly related to #181

EDIT: digging a bit more I see

$ tar -tzf go-1.20.14-darwin-arm64.tar.gz | grep 'src/runtime/.*syso'
./src/runtime/race/internal/amd64v1/race_windows.syso
./src/runtime/race/internal/amd64v1/race_darwin.syso
./src/runtime/race/internal/amd64v1/race_linux.syso
./src/runtime/race/internal/amd64v1/race_freebsd.syso
./src/runtime/race/internal/amd64v1/race_netbsd.syso
./src/runtime/race/internal/amd64v1/race_openbsd.syso
./src/runtime/race/internal/amd64v3/race_linux.syso
./src/runtime/race/race_darwin_arm64.syso
./src/runtime/race/syso_test.go
$ tar -tzf go1.18.10.darwin-arm64.tar.gz | grep 'src/runtime/.*syso'
go/src/runtime/race/race_darwin_arm64.syso
go/src/runtime/race/syso_test.go

files take from:

• https://github.com/actions/go-versions/blob/74d3ad35e25603a981b7fed05ea4103d03cb7bbb/versions-manifest.json#L504
• https://github.com/actions/go-versions/blob/74d3ad35e25603a981b7fed05ea4103d03cb7bbb/versions-manifest.json#L921

Indeed I see the same output in the upstream download from https://go.dev/dl/#go1.20.14 🤔 I wonder if those are meant to be there (via tar -tzf go1.20.14.darwin-arm64.tar.gz | grep 'src/runtime/.*syso') ... indeed it looks like the build process has involved quite a bit over time and I guess those are expected now

[gowridurgad]

Hi @timandy, When GOOS and GOARCH are manually specified, the Go compiler typically enters cross-compilation mode and defaults CGO_ENABLED to '0', effectively disabling cgo.

Exceptions exist for certain platforms, notably Linux and Windows. Even with GOOS and GOARCH manually set, CGO_ENABLED remains '1', leaving cgo enabled. This is attributed to Go's reliable support for these platforms.
In the case of macOS, despite the build system matching the target system, Go maintains its general rule for cross-compilation, setting CGO_ENABLED to '0'.

These are default behaviors and can be overridden if necessary. For example, if macOS builds necessitate cgo, CGO_ENABLED can be manually set to '1'. However, the build environment must be capable of cross-compiling C code for macOS.

env:
  CGO_ENABLED: 1

[timandy]

@gowridurgad Thanks for your detailed answer, I will close this issue now.

[timandy]

@gowridurgad Sorry for reopen this issue.
I want to known why go1.18 and go1.19 on mac can't run race test, But go1.20+ can, Is this situation normal?

https://github.com/timandy/routine/actions/runs/9475193593/job/26106126731

      # darwin
      - name: 'Test on [darwin] arch [amd64]'
        if: ${{ matrix.os == 'darwin' && contains(fromJson('["amd64"]'), matrix.arch) }}
        env:
          GOOS: ${{ matrix.os }}
          GOARCH: ${{ matrix.arch }}
          CGO_ENABLED: 1
        run: |
          echo ${CGO_ENABLED}
          go env CGO_ENABLED
          go test -v -race -coverprofile="coverage.txt" -covermode=atomic ./...

[matthewhughes934]

@gowridurgad Sorry for reopen this issue. I want to known why go1.18 and go1.19 on mac can't run race test, But go1.20+ can, Is this situation normal?

Following from what I found above, I believe this is due to a change in how Go is built upstream, given the errors you see look to be similar to those in golang/go#42382 (i.e. missing runtime/race/*.syso files)

• With golang/build@bbe91e8 Go builds no longer included those *.syso files
• Go 1.18, 1.19 were built with that system and are hence don't include those files
• Sometime after, they moved to a new build system which I believe doesn't strip these (I can't find evidence that it does...), the old build system was removed with golang/build@97ad0ce. Note the date is just after the release of Go 1.20, so I suspect that was built with the new system (including the files, hence race tests working)

based on the above, I suspect that if you also tried to build on Go 1.17 (or older) you'd see the issue there too

[timandy]

@matthewhughes934 Thanks a lot. I found that github has upgrade macos-lastest to M1 CPU. That cause my amd64 race test work flow runs on arm64.

[gowridurgad]

Hi @timandy, Starting from Go version 1.20, the dependency on cgo for the race detector has been removed on macOS. This allows for the building and running of programs with the race detector enabled without the requirement of Xcode. So From Go version 1.20 onwards, the race test can be executed successfully, regardless of whether CGO_ENABLED is set to '0' or '1'.. It's important to note that for Linux, other Unix systems, and Windows, a host C toolchain remains necessary to use the race
detector. This information is documented in the official Go release notes.

The build failure, even with CGO enabled (CGO_ENABLED=1), is due to a mismatch between the build and target architectures. In this case, the build architecture is ARM64, while the target architecture is AMD64. However, by disabling the race detector, the workflow runs successfully. Her's the screenshots for your reference.
Please feel to reach out us in case of any concerns. Thank you once again.