-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
go/build: default Context.ToolTags doesn't contain GOAMD64 setting from user config file #72791
Comments
build.Default.ToolTags
from go/build
ignores GOAMD64=v2
from the user's environment *file* (not variable)
Related Issues
Related Code Changes (Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.) |
That's an interesting case. The file set by I'm not sure that there is anything we can do here. |
If the user builds an initrd for amd64, and their golang toolchain is configured for an amd64 ABI version greater than 1, then issue a warning. Binaries built for GOAMD64=v2+ may crash with an #UD exception on old CPUs, or exit immediately (gracefully) with an error message like "This program can only be run on AMD64 processors with v2 microarchitecture support" [1]. Such a dysfunctional "init" (gobusybox) binary renders a u-root initrd effectively unbootable. qemu-system-x86_64 with no particular "-cpu" option is affected by this, for example. GOAMD64 defaults to v1 [2], but it may be overridden in at least three places (in increasing order of importance): - the system-wide "go.env" file, such as "/usr/lib/golang/go.env", - the user's "go.env" file, such as "$HOME/.config/go/env", - the env var GOAMD64. For example, RHEL9 and its derivative distros set GOAMD64 to v2 in "/usr/lib/golang/go.env". It seems like the canonical way for deducing GOAMD64 programmatically is to invoke "go env GOAMD64" [3]. [1] golang/go@8c8baad927b2 [2] https://go.dev/wiki/MinimumRequirements#amd64 [3] golang/go#72791 Signed-off-by: Laszlo Ersek <[email protected]>
What version of Go are you using (
go version
)?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 withgo bug
from upstream (at commit 73fea03).What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
where
tooltags.go
isWhat did you expect to see?
What did you see instead?
The
amd64.v2
tool tag is missing frombuild.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
The text was updated successfully, but these errors were encountered: