go/build: default Context.ToolTags doesn't contain GOAMD64 setting from user config file

[lersek]

What version of Go are you using (go version)?

$ go version
go version devel go1.25-73fea035bf1e Tue Mar 11 07:51:38 2025 -0700 linux/amd64

Does this issue reproduce with the latest release?

The reproducer is even more recent than the latest release (commit 73fea03 is the current HEAD of the master branch).

I originally encountered the symptom with my distro's go (go version go1.22.9 (Red Hat 1.22.9-2.el9_5) linux/amd64), but the problem reproduces with current upstream, too. The bug is being reported with go bug from upstream (at commit 73fea03).

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
AR='ar'
CC='gcc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE=''
GOAMD64='v2'
GOARCH='amd64'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/home/lacos/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/home/lacos/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build1652133164=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/dev/null'
GOMODCACHE='/home/lacos/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/lacos/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/home/lacos/src/upstream/go'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/lacos/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/home/lacos/src/upstream/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='devel go1.25-73fea035bf1e Tue Mar 11 07:51:38 2025 -0700'
GOWORK=''
PKG_CONFIG='pkg-config'
GOROOT/bin/go version: go version devel go1.25-73fea035bf1e Tue Mar 11 07:51:38 2025 -0700 linux/amd64
GOROOT/bin/go tool compile -V: compile version devel go1.25-73fea035bf1e Tue Mar 11 07:51:38 2025 -0700
uname -sr: Linux 5.14.0-503.26.1.el9_5.x86_64
/lib64/libc.so.6: GNU C Library (GNU libc) stable release version 2.34.

What did you do?

$ go env -w GOAMD64=v2
$ go env | grep -w GOAMD64
$ go run tooltags.go

where tooltags.go is

package main

import (
        "fmt"
        "go/build"
)

func main() {
        fmt.Println(build.Default.ToolTags)
}

What did you expect to see?

GOAMD64='v2'
[goexperiment.regabiwrappers goexperiment.regabiargs goexperiment.aliastypeparams goexperiment.swissmap goexperiment.spinbitmutex goexperiment.synchashtriemap amd64.v1 amd64.v2]

What did you see instead?

GOAMD64='v2'
[goexperiment.regabiwrappers goexperiment.regabiargs goexperiment.aliastypeparams goexperiment.swissmap goexperiment.spinbitmutex goexperiment.synchashtriemap amd64.v1]

The amd64.v2 tool tag is missing from build.Default.ToolTags.

Note that if I pass GOAMD64=v2 as an environment variable (i.e., not through my environment file /home/lacos/.config/go/env), then the result is as expected.

This issue breaks ABI level checks such as

go/src/cmd/compile/internal/amd64/versions_test.go

Line 41 in 73fea03

if tag == "amd64.v2" {

[gabyhelp]

Related Issues

• go version go1.21.5 linux/amd64 #67008 (closed)
• cmd/go: improve documentation of GOAMD64 environment variable #50174 (closed)
• some issues here ! #39105 (closed)
• go build #51949 (closed)
• affected/package: toolchain test/fixedbugs/10607 #62399 (closed)
• go1.23.4 linux/amd64 completely broken #70732 (closed)
• go env #65011 (closed)
• Bughunter #70775 (closed)
• Bug #70776 (closed)

Related Code Changes

• cmd/compile/internal/amd64: more robust detection of GOAMD64=v1

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

[ianlancetaylor]

That's an interesting case. The file set by go env -w is read by the go tool and the commands that it runs. It is not read by all Go programs. However, environment variables are read by all Go programs. So when you run an arbitrary Go program, such as your tooltags program, it will see the environment variables, but it won't see the variables set by go env -w.

I'm not sure that there is anything we can do here.

[lersek]

@ianlancetaylor Thank you for the feedback!

I'm not sure that there is anything we can do here.

I figured that whatever populates build.Default.ToolTags upon "program startup" (fuzzy term, I know), could just go ahead and read the env files as well.

At the same time, I've found a solution -- I can write

abi_level, err := exec.Command("go", "env", "GOAMD64").Output()

and verify the byte array abi_level (and handle errors properly, of course).

I'm OK if we close this ticket as "not planned" now. Thank you again for the help.

[ianlancetaylor]

I figured that whatever populates build.Default.ToolTags upon "program startup" (fuzzy term, I know), could just go ahead and read the env files as well.

It's not a big deal for the Go tools to read that file. It would be a big change for every Go program to read that file. And the documentation is that the file only affects the Go tools.

Closing. Thanks.