go: cmd/go: TestScript/list_std_stale fails if CGO_CFLAGS was set to a custom value during ./make.bash

As found by @bcmills in #46292, this happens on tip (tested with commit 52d7033ff6d56094b7fa852bbdf51b4525bd6bb2).

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/dmitshur/Library/Caches/go-build"
GOENV="/Users/dmitshur/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/dmitshur/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/dmitshur/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/dmitshur/gotip"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/dmitshur/gotip/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="devel go1.17-52d7033ff6 Mon May 24 15:03:18 2021 +0000"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/dmitshur/gotip/src/go.mod"
CGO_CFLAGS="-O3"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/zb/5p8cwfhj29gf_m8vdy8ylmlr00jwcj/T/go-build1142646826=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

# Set CGO_CFLAGS in environment.
$ export CGO_CFLAGS='-O3'

# Build Go and run a test.
$ cd gotip/src
$ ./make.bash
$ export PATH="$(cd ../bin; pwd):$PATH"
$ go test -run=TestScript/list_std_stale -short -count=1 cmd/go

What did you expect to see?

A test result that verifies issue #44725 is fixed, or a skipped test execution if the current environment doesn’t make it possible to run the test reliably.

What did you see instead?

The test fails if ./make.bash was run with CGO_CFLAGS set as above.

go test proxy running at GOPROXY=http://127.0.0.1:51387/mod
--- FAIL: TestScript (0.01s)
    --- FAIL: TestScript/list_std_stale (0.24s)
        script_test.go:252: 
            # https://golang.org/issue/44725: packages in std should not be reported as stale,
            # regardless of whether they are listed from within or outside GOROOT/src.
            # Control case: net should not be stale at the start of the test,
            # and should depend on vendor/golang.org/… instead of golang.org/…. (0.186s)
            > ! stale net
            FAIL: testdata/script/list_std_stale.txt:7: net is unexpectedly stale
            
            
FAIL
FAIL	cmd/go	1.683s
FAIL

Unsetting the env var afterwards doesn’t make a difference:

$ unset CGO_CFLAGS
$ go test -run=TestScript/list_std_stale -short -count=1 cmd/go
[...]
FAIL	cmd/go	1.605s

Edit: Simplified reproduce case from CGO_CFLAGS='-mmacosx-version-min=10.13' to CGO_CFLAGS='-O3'.

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 22 (20 by maintainers)

Commits related to this issue

cmd/go: rewrite TestScript/cgo_stale_precompiled to be agnostic to staleness The configuration set by x/build/cmd/releasebot causes runtime/cgo to be stale in the darwin/amd64 release (see #36025, #3... — committed to golang/go by bcmills 2 years ago

Most upvoted comments

I’m not sure exactly what that implies — we don’t generally cache binaries, so is it possible that cmd/cgo is being reinstalled on users’ machines, or relinked from the build cache every time a macOS user builds any package involving cgo?

I don’t think we check binary staleness when invoking a tool binary. The go command just invokes the installed binary, whether it is stale or not.

cherrymui on May 24, 2021

cmd/link.TestDWARF and cmd/link.TestDWARFiOS require that cmd/link itself is not stale.

I still think that test should not check linker staleness at all. (This was added just to help local development.)

cherrymui on May 25, 2021

I think the idea is that the behavior of the toolchain ought to be independent of the user’s environment — especially given that the Go toolchain may be installed by a system administrator but run by an individual user — and most users should not need to set CGO_CFLAGS explicitly.

This sounds like we may want to somehow bake the make.bash-time CGO_CFLAGS into the toolchain.

On the other hand, what if a user just wants to set CGO_CFLAGS when building the standard library and toolchain, but not when building user code? Or maybe nobody wants to do that…

cherrymui on May 24, 2021