Related Issues

• cmd/dist: I/O error: read src/xxx.go: is a directory #35776 (closed)
• x/benchmarks/sweet/cmd/sweet: TestSweetEndToEnd failing with gvisor build errors since CL 386698 #51445
• cmd/go: build failure on a machine with gccgo installed after commit 38431f1044 #32060 (closed)
• cmd/go: locating GOROOT fails when the `go` command is run from the cross-compiled `bin` subdirectory #62119 (closed)
• cmd/link: buildmode=shared with many packages produces "file name too long" error #38330 (closed)
• x/build: build failures due to `410 Gone` responses from `symbolic-datum-552` GOPROXY #53572
• build: the build of go bootstrap in case of compilation errors does not stop cleanly #45410 (closed)
• x/tools/cmd/getgo: cannot install Go 1.21 #63367 (closed)
• cmd/go: TestScript/gotoolchain_issue66175 fails on tip locally #67277 (closed)
• cmd/dist: trying to build Go from source at tip on Windows / WSL incorrectly tries to download a go1.24.0 toolchain #70533 (closed)

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

The cause is go1.23.0 in go.mod. As described in toolchain, when using go1.22.0 in sweet, go1.23.0 will be tried.

For example, when using the go command bundled with Go 1.21.3 in a main module that says go 1.21.9, the go command finds and runs Go 1.21.9 instead.

Besides, the possible reason for "permission denied" is that the automatically downloaded toolchain is read-only. So installing cmd/compile and cmd/link is not allowed. The permissions for these file are as follows:

.r-xr-xr-x  20M  20M lqw lqw 17 3月  21:46 compile
.r-xr-xr-x 5.7M 5.7M lqw lqw 17 3月  21:46 link

Support more go versions might be beneficial. But using new Go version is welcomed possibly.

I think for benchmarking purposes, it should run with the exact Go toolchain specified in the config file. No auto-download etc.. Especially for working on the Go toolchain, this ensures we're benchmarking the toolchain we are actually working on. Otherwise it would be confusing.

Perhaps we should run the install command in the goroot directory. And perhaps we want to set GOTOOLCHAIN=local.

Support more go versions might be beneficial. But using new Go version is welcomed possibly.

Could be, but as a separate feature. E.g. we can have a special syntax in the config file to specify go1.24.1 and let the runner automatically download it. But this should be explicit.

cc @mknyszek @golang/runtime

Sorry for the ambiguity.

Support more go versions might be beneficial.

Here I mean supporting older versions like go1.22.0 might be beneficial for ones working on older versions. go1.24.1 is supported currently. go1.22.0 however is not supported.

But using new Go version is welcomed possibly.

Here I mean always using the latest Go is a good practice.

Supporting older versions like go1.22.0 in a benchmark may not be a top priority and can be quite challenging. This is because, firstly, dependency issues need to be resolved. Secondly, older versions often have inferior functionality and performance compared to newer ones. So, it's likely to be an ungrateful task. Therefore I say "using new Go version is welcomed possibly".

I tried to change go version in go.mod to go1.22.0. And there is dependency issue as follows, which is expected. This is a wrong direction because the version of go to build cmd/sweet is not important. I realised this later.

go.mod:

...
go 1.22.0

downloading go1.23.7 automatically because of dependency issue.

(base) ➜  benchmarks git:(understand) ✗ /home/lqw/golangs/go1.22.0/bin/go mod tidy                     
go: golang.org/x/sys@v0.31.0 requires go >= 1.23.0; switching to go1.23.7
go: downloading go1.23.7 (linux/amd64)
^C

After using the following configuration and replacing "" with "cfg.GoRoot" in sweet/harnesses/go-build.go#L114, I successfully build other benchmarks except cmd/tsgo which requires go1.24.0.

[[config]]
    name = "go1.22.0"
    goroot = "/home/lqw/golangs/go1.22.0"
    envbuild = ["GOTOOLCHAIN=go1.22.0"]
    envexec = ["GOTOOLCHAIN=local"]

$ ./sweet run -work-dir /data/sweet-work -shell -run go-build go1.22.0.toml
...
[shell] cd /data/sweet-work/go-build/go1.22.0/bin/tsgo/cmd/tsgo
[shell] GOROOT=/data/sweet-work/go-build/go1.22.0/bin/goroot GOTOOLCHAIN=local /data/sweet-work/go-build/go1.22.0/bin/goroot/bin/go build -o /data/sweet-work/go-build/go1.22.0/bin/dummy
[shell] cd /home/lqw/mygit/research/vm/go-bench/benchmarks/sweet
[sweet] error: build go-build for go1.22.0: error building tsgo cmd/tsgo: exit status 1. stderr:
go: errors parsing ../../go.mod:
../../go.mod:20: unknown directive: tool
[sweet] error: failed to execute benchmarks: go-build

After removing cmd/tsgo, a new error occurs. The benchmark go-build itself requires >=go1.23.0 but GOROOT is go1.22.0.

[shell] cd /home/lqw/mygit/research/vm/go-bench/benchmarks/sweet
[sweet] error: build go-build for go1.22.0: error building go-build tool: exit status 1. stderr:
go: ../../../go.mod requires go >= 1.23.0 (running go 1.22.0; GOTOOLCHAIN=go1.22.0)
[sweet] error: failed to execute benchmarks: go-build

Possibly envbuild and envexec can use different toolchains instead of sharing one GOROOT.

Thanks for the pointer to GOTOOLCHAIN=local.

But I give up to support go1.22.0.