Compile cmd/pack from source and update to Go 1.25
#4425
Conversation
…g/tool" In go1.25 the "cmd/pack" command is no longer shipped with Go distributions, which results is build failures that look like ``` Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging 2025-06-09 00:44:46 PDT compilepkg: error running subcommand external/go_sdk/pkg/tool/linux_amd64/pack: fork/exec external/go_sdk/pkg/tool/linux_amd64/pack: no such file or directory 2025-06-09 00:44:46 PDT ERROR: /home/testuser/.cache/bazel-single-base/external/io_nhooyr_websocket/BUILD.bazel:3:11: GoCompilePkg external/io_nhooyr_websocket/websocket.a failed: (Exit 1): builder failed: error executing GoCompilePkg command (from target @@io_nhooyr_websocket//:websocket) bazel-out/k8-opt-exec-ST-a828a81199fe/bin/external/go_sdk/builder_reset/builder compilepkg -sdk external/go_sdk -goroot bazel-out/k8-fastbuild/bin/external/io_bazel_rules_go/stdlib_ -installsuffix ... (remaining 63 arguments skipped) ``` Since the pack command is used to compile Go programs (in compilepkg.go) we need to build it from source. golang/go#74080 #4398
fmeum
force-pushed
the
fmeum/exec-pack
branch
2 times, most recently
from
20c89e2 to
2e7304d
Compare
fmeum
changed the title
cmd/pack from source and update to Go 1.25
sluongng
left a comment
sluongng
left a comment
There was a problem hiding this comment.
I think the current approach is fine. What's a bit concerning to me is for folks who use the Bazel-managed gosdk for other tools (vscode, golangcilint, etc...). In those cases the gosdk won't have a cmd/pack tool to use and would still end up rebuilding one for the host? 🤔
I guess that's technically fine since building pack from source should be relatively fast.
I don't feel bad for doing exactly what the vanilla Go SDK would do in that case :-D |
dzbarsky
left a comment
dzbarsky
left a comment
There was a problem hiding this comment.
Nice, doing this as part of the builder makes a lot of sense
r-hang
left a comment
r-hang
left a comment
There was a problem hiding this comment.
nice! looks good to me. i'll close my PR.
What type of PR is this?
Fix for compatibility with Go 1.25
What does this PR do? Why is it needed?
The
packcommand, which is no longer shipped as a prebuilt binary with Go 1.25, is now compiled from source together with thebuilderbinary.Conditional logic is avoided by always compiling
packfrom source, even on Go versions before 1.25. By enablinggo buildcaching ingo_tool_binary, the overhead compared to building just thebuilderbinary is negligible.Which issues(s) does this PR fix?
ref: golang/go#74080
fixes #4398
Other notes for review