Closed
Description
Go version
go version go1.22.4 darwin/arm64
Output of go env
in your module/workspace:
GO111MODULE=''
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/sekai/Library/Caches/go-build'
GOENV='/Users/sekai/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/sekai/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/sekai/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/opt/homebrew/Cellar/go/1.22.4/libexec'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/opt/homebrew/Cellar/go/1.22.4/libexec/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.22.4'
GCCGO='gccgo'
AR='ar'
CC='cc'
CXX='c++'
CGO_ENABLED='1'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/62/0rdd_81n5jbf6j4w3pcmwycr0000gn/T/go-build3068982710=/tmp/go-build -gno-record-gcc-switches -fno-common'
What did you do?
I am updating golang.org/x/crypto to v0.24.0. Many third-party libraries and other x libraries also depend on this version.
What did you see happen?
It fails to compile with Go 1.18:
# golang.org/x/crypto/sha3
sha3/xor.go:25:10: undefined: subtle.XORBytes
What did you expect to see?
Since many third-party libraries and other x libraries actually still compile under Go 1.18, and the go mod for x/crypto still use Go 1.18, it would be nice if crypto treated this as a bug.
subtle.XORBytes looks like a public version of the internal function crypto/cipher.xorBytes , if you don't want to copy a compat version of the old code for Go 1.18 you can linkname to it (I know linkname shouldn't be used, but maybe ok for older Go versions)
Activity
gabyhelp commentedon Jun 24, 2024
Similar Issues
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)
seankhliao commentedon Jun 24, 2024
that is not a version of go we still support.
wwqgtxx commentedon Jun 24, 2024
This reply is too arrogant. Since the
go.mod
ofx/crypto
is written in 1.18, it should be guaranteed to compile normally under 1.18.wwqgtxx commentedon Jun 24, 2024
Perhaps we should ask @FiloSottile, who caused the compilation problem, what his attitude is on this.
FiloSottile commentedon Jun 24, 2024
We indeed don't support such old versions of Go. We put a lot of effort into making it possible to upgrade Go without breakage, partially so we don't have to worry about supporting older versions.
It's true the go.mod says Go 1.18 though, which probably shouldn't. It caused confusion in #68035, too, and #68011 would have gotten a hint if the go.mod version was higher.
This is really an instance of #47802, in general, but was not flagged by vet due to #46136 (comment).
Questions for @golang/release: is there a policy on how to bump go.mod versions of x/ repos?
@wwqgtxx maintainers have a thankless job, please don't attack them just because you don't appreciate a response.
wwqgtxx commentedon Jun 24, 2024
Maybe my wording is not appropriate, I apologize in advance, but it is not what the maintainer should do to ignore the three issues including this one.
Regarding this issue, either the go version number in
x/crypto
should be increased, or conditional compilation should be used to maintain normal compilation.If the official compatibility policy for old versions has not been discussed internally, at least this issue should be kept open instead of being closed rudely.
FiloSottile commentedon Jun 24, 2024
Yes, that's what we are discussing now, but again please be considerate and keep the conversation on the topic rather than on individual's actions you disagree with, unless strictly necessary. I promise it will lead to better outcomes anyway.
gopherbot commentedon Jun 24, 2024
Change https://go.dev/cl/594256 mentions this issue:
all: bump go.mod version and drop compatibility shims
dmitshur commentedon Jun 24, 2024
@FiloSottile There isn't something written down beyond the Go release policy, but that policy suggests general golang.org/x modules (e.g., with user-facing importable packages) need to continue to support the current and previous major Go versions (with some exceptions like the one for x/build). That's 1.22 and 1.21 at this time. So it's fine to update the x/crypto module to use Go 1.20 language semantics by now, since all supported Go versions can handle that, and the 1.22/1.21 trybots should pass.
11 remaining items