Golang cmd/go: built-in tools built on demand don't respect most of the build settings

Go version

go version go1.25rc2 darwin/arm64

Output of go env in your module/workspace:

R='ar'
CC='clang'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='clang++'
GCCGO='gccgo'
GO111MODULE=''
GOARCH='arm64'
GOARM64='v8.0'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/Users/qmuntaldiaz/Library/Caches/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/Users/qmuntaldiaz/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/6_/bk27w0c510ld88800_hfj6j00000gn/T/go-build3067268774=/tmp/go-build -gno-record-gcc-switches -fno-common'
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMOD='/Users/qmuntaldiaz/code/golang-go/src/go.mod'
GOMODCACHE='/Users/qmuntaldiaz/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/qmuntaldiaz/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/Users/qmuntaldiaz/sdk/go1.25rc2'
GOSUMDB='sum.golang.org'
GOTELEMETRY='on'
GOTELEMETRYDIR='/Users/qmuntaldiaz/Library/Application Support/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/Users/qmuntaldiaz/sdk/go1.25rc2/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.25rc2'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

go1.25rc2 version -m $(go tool -n nm)

What did you see happen?

../nm: go1.25rc2
        path    cmd/nm
        build   -buildmode=exe
        build   -compiler=gc
        build   CGO_ENABLED=1
        build   CGO_CFLAGS=
        build   CGO_CPPFLAGS=
        build   CGO_CXXFLAGS=
        build   CGO_LDFLAGS=
        build   GOARCH=arm64
        build   GOOS=darwin
        build   GOARM64=v8.0

What did you expect to see?

../nm: go1.25rc2
        path    cmd/nm
        build   -buildmode=exe
        build   -compiler=gc
        build   -trimpath=true
        build   CGO_ENABLED=0
        build   GOARCH=arm64
        build   GOOS=darwin
        build   GOARM64=v8.0

Note that CGO_ENABLED and trimpath are different. This issue is exacerbated when manually building the Go toolchain with custom flags, as I do, e.g. GO_GCFLAGS=-N ./make.bash.

Related to #71867.

@matloob @dmitshur

Comment From: qmuntal

Tentatively marking as release blocker, as this is a regression introduced in Go 1.25 due to #71867.

Comment From: gabyhelp

Related Issues

• go tool compile #55111 (closed)
• cmd/go/internal/work/security.go: invalid flag in `#cgo LDFLAGS: -Wl,-rpath,.` #70924 (closed)
• cmd/go/internal/work/security.go: invalid flag in `#cgo darwin LDFLAGS: -Wl,-rpath -Wl,@loader_path` #70923 (closed)
• cmd/go: using `--trimpath` in `go build` removes `-ldflags` from `go version -m` output #63432
• cmd/go: go env -changed prints changed values for variables in go.env #67542 (closed)
• cmd/go/internal/load: -ldflags should be included in buildinfo when -trimpath is set and CGO_ENABLED=0 #63558 (closed)
• cmd/cgo: compilation failure on Apple silicon when GOHOSTARCH=arm64 and GOARCH=amd64 #43476 (closed)
• go build #52634 (closed)
• cmd/go get doesn't validate module arguments #71437 (closed)
• cmd/go: buildmode is not set in build settings #53856 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

Comment From: seankhliao

I think the settings match the ones you provided in your environment? I'd be very surprised if flags passed in the command line for building cmd/go somehow made it into tools built later on demand

Comment From: qmuntal

I think the settings match the ones you provided in your environment? I'd be very surprised if flags passed in the command line for building cmd/go somehow made it into tools built later on demand

Yes, that's the current behavior. My point is that in Go 1.24 all the built-in tools where built with the same flags, while in Go 1.25 the flags depend on whether the tool is build eagerly or lazily.

This new behavior breaks some of my workflows, as I expect all the built-in tools to have the same build tags. Having said this, I acknowledge that m use-case is niche, and I'm already forking the Go toolchain in many ways, so I don't mind forking it a bit more.

The main goal of this issue is to surface this behavior change and make sure it is accepted before we cut the release, as I haven't seen it discussed in #71867.

Comment From: dmitshur

CC @golang/command-line.

Comment From: matloob

Yeah, we expect this behavior. The goal was to keep the behavior of running the tools using go tool <tool> the same. So we have to make sure that we build the tools using the same "host configuration" GOOS and GOARCH the toolchain was built with, but in general we can't guarantee the same configuration.

I'm curious about your workflow: how does it break? Are there only specific bits of the configuration your workflow is sensitive to?