x/build/cmd/golangbuild: support toolchain upgrades when testing GOARCH=wasm ports #71902
Labels
arch-wasm
WebAssembly issues
Builders
x/build issues (builders, bots, dashboards)
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
The first GOARCH=wasm port was added in Go 1.11, way before the Go 1.21 toolchain selection/switching behavior was added.
Builders that needed to test the port rely on cmd/go's support for executing non-host binaries via go_goos_goarch_exec helpers. Such a helper needs to be made available in PATH, and the builders did that. In Go 1.24, the path changed, so the builders add both locations, which works both when testing Go 1.23 and 1.24+:
https://source.chromium.org/chromium/infra/infra_superproject/+/main:infra/go/src/infra/experimental/golangbuild/buildspec.go;l=255-259;drc=d158479cea677154e162ed205706717645e7b437
As documented at https://go.dev/wiki/WebAssembly:
That also applies to the helper go_*_wasm_exec helper and its wasm_exec_node.js support file.
The builders are responsible for selecting the exact initial Go toolchain commit to be tested and in most cases test with the local toolchain built from that very commit, which is why the original behavior has continued to work most of the time. However, in some cases builders permit the go command to select/switch to another toolchain (the new Go 1.21+ behavior). That means it can inadvertently result in the go_*_wasm_exec helper and wasm_exec.js file being used from one major Go version (e.g., 1.23) while after the toolchain selection/switching it may be a different one (e.g., 1.24). That's a bug in the builder and needs to be fixed. It's causing the failures observed in #71883 now.
CC @golang/release, @golang/wasm.
Issue #68024 is relevant here. Now that it's fixed, it's viable for the builders to start using the support files in GOROOT/lib/wasm from downloaded toolchains. (Prior to that issue being resolved, those files weren't being included.)
Unfortunately, it's fixed only in Go 1.24, resolving this will not directly help the 1.23 builders running into #71883.
The text was updated successfully, but these errors were encountered: