cmd/dist: trying to build Go from source at tip on Windows / WSL incorrectly tries to download a go1.24.0 toolchain

[bitlux]

Go version

go version go1.23.2 windows/amd64

Output of go env in your module/workspace:

$ pwd
/mnt/c/Users/Adam/projects/go.googlesource.com
$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\Adam\AppData\Local\go-build
set GOENV=C:\Users\Adam\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\Adam\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\Adam\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLCHAIN=auto
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.23.2
set GODEBUG=
set GOTELEMETRY=on
set GOTELEMETRYDIR=C:\Users\Adam\AppData\Roaming\go\telemetry
set GCCGO=gccgo
set GOAMD64=v1
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=0
set GOMOD=NUL
set GOWORK=
set CGO_CFLAGS=-O2 -g
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-O2 -g
set CGO_FFLAGS=-O2 -g
set CGO_LDFLAGS=-O2 -g
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -fno-caret-diagnostics -Qunused-arguments -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=C:\Users\Adam\AppData\Local\Temp\go-build3725220361=/tmp/go-build -gno-record-gcc-switches
/mnt/c/Users/Adam/projects/go.googlesource.com $

What did you do?

I am using a combination of Windows and WSL. My go installation is in Windows; I have go as a symlink to /mnt/c/Program Files/Go/bin/go.exe. My shell is a WSL bash shell.

I cloned the Go source repo as per https://go.dev/doc/contribute#gerrit_overview:

 $ git clone https://go.googlesource.com/go
Cloning into 'go'...
remote: Sending approximately 575.75 MiB ...
remote: Counting objects: 22, done
remote: Total 636425 (delta 456293), reused 636425 (delta 456293)
Receiving objects: 100% (636425/636425), 574.48 MiB | 3.94 MiB/s, done.
Resolving deltas: 100% (456293/456293), done.
Updating files: 100% (14190/14190), done.

When I tried to run ./all.bash, I get this error:

$ ./all.bash
go: downloading go1.24.0 (windows/amd64)
go: download go1.24.0 for windows/amd64: toolchain not available

Indeed, all go commands return this error when I am in this directory:

/mnt/c/Users/Adam/projects $ go version
go version go1.23.2 windows/amd64
/mnt/c/Users/Adam/projects $ cd go.googlesource.com/
/mnt/c/Users/Adam/projects/go.googlesource.com $ go version
go version go1.23.2 windows/amd64
/mnt/c/Users/Adam/projects/go.googlesource.com $ cd go
/mnt/c/Users/Adam/projects/go.googlesource.com/go $ go version
go version go1.23.2 windows/amd64
/mnt/c/Users/Adam/projects/go.googlesource.com/go $ cd src
/mnt/c/Users/Adam/projects/go.googlesource.com/go/src $ go version
go: downloading go1.24.0 (windows/amd64)
go: download go1.24.0 for windows/amd64: toolchain not available

Here is the cloned go.mod file:

$ cat go.mod
module std

go 1.24

require (
        golang.org/x/crypto v0.29.0
        golang.org/x/net v0.31.1-0.20241122011411-9a518991035b
)

require (
        golang.org/x/sys v0.27.1-0.20241118193836-0a57dbcf35b2 // indirect
        golang.org/x/text v0.20.0 // indirect
)

What did you see happen?

$ go version
go: downloading go1.24.0 (windows/amd64)
go: download go1.24.0 for windows/amd64: toolchain not available

What did you expect to see?

$ go version
go version go1.23.2 windows/amd64

[gabyhelp]

Related Issues

• error gopath #66295 (closed)
• cmd/go: go1.22 toolchain not available #65631 (closed)
• Build Issue on Windows #44782 (closed)
• x/website: #45769 (closed)
• x/build/cmd/gorebuild: uses wrong path separator for running make.bat on Windows #61951 (closed)
• go command #62170 (closed)
• cmd/go: fails with `go: cannot find GOROOT directory` after cross-compiling from WSL to Windows. #45763 (closed)
• cmd/go: mod tidy reports toolchain not available with 'go 1.21' #62278 (closed)
• cmd/go: toolchain downloads fails with `verifying module: invalid GOSUMDB: malformed verifier id` #68782 (closed)
• build golang #45438 (closed)

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

[dmitshur]

From your description, it sounds like there's something going wrong when you're building Go from source.

I'm not sure if you're running into some problem that only affects the combination of Windows and WSL, or if something else is causing trouble.

Here are some ideas for what you could try, and report back on what the outcome is:

1. What happens if you run all.bat instead of all.bash?

   Normally, on Windows, all.bat is expected to be used, though maybe all.bash is right for WSL.

2. If you have access to another machine with a different OS, are you able to build Go from source there?

   That is, it'd help to understand if this only happening on Windows/WSL, or are you seeing the same behavior elsewhere too.

CC @golang/windows.

[bitlux]

What happens if you run all.bat instead of all.bash?

If I run it in bash, I get a bunch of errors. If I run it in Command Prompt, it appears to build the toolchain. Preliminary results:

C:\Users\Adam\projects\go.googlesource.com\go\src>all.bat
Building Go cmd/dist using C:\Program Files\Go. (go1.23.2 windows/amd64)
Building Go toolchain1 using C:\Program Files\Go.
Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
Building Go toolchain2 using go_bootstrap and Go toolchain1.

If you have access to another machine with a different OS, are you able to build Go from source there?

Sadly I don't have access to another machine. Using this Windows machine is sort of a last resort. :-\

[dagood]

My go installation is in Windows; I have go as a symlink to /mnt/c/Program Files/Go/bin/go.exe. My shell is a WSL bash shell.

I have a few questions about this arrangement if you don't mind:

• What is the goal? Why build in WSL?
• Do you want the end result to be a Go toolset that will run on linux, or on windows?
• Can you install a Linux copy of Go as your bootstrap inside WSL (and does that work)?

I haven't used WSL all that much, but when I have, it's so that I can run Linuxy apps and processes--wondering if there's some workflows I'm not seeing.

[bitlux]

What is the goal? Why build in WSL?

TLDR: I prefer bash to PowerShell or Command Prompt.

I need to run Windows-specific software, so I have a Windows machine. But all of my development experience is in Unix-based OSes, so I installed WSL to replicate that environment. As time went on, I ran into problems with this setup. One in particular was trying to use git codereview for Gerrit; when I ran git codereview from WSL (where git is /usr/bin/git), the codereview tool was executing /mnt/c/Program Files/Git/cmd/git.exe when it tried to run Git commands (I looked in the codereview source to see why this was happening, and couldn't find anything obvious). As part of the fix for that, I moved to a Windows-based (but still bash-driven) development environment, including aliasing git to git.exe (which is /mnt/c/Program Files/Git/cmd/git.exe), as per the recommendation of a Stackoverflow thread that I cannot find now.

Do you want the end result to be a Go toolset that will run on linux, or on windows?

Ideally Windows, for the reasons I mentioned above, but I would be happy with either.

Can you install a Linux copy of Go as your bootstrap inside WSL (and does that work)?

I will try. :)

[seankhliao]

what does go tool dist env output, in both cmd and wsl?

[bitlux]

what does go tool dist env output, in both cmd and wsl?

wsl$ /mnt/c/Program\ Files/Go/bin/go.exe tool dist env
go: no such tool "dist"

cmd>go tool dist env
go: no such tool "dist"

[dagood]

Have you set up WSLENV for Go? I reproduce your error message if I don't have it set up, and if I set it up, I get a different error:

$ export WSLENV=GOROOT/p:GOROOT_BOOTSTRAP/p:GOOS:GOARCH:GOEXPERIMENT:GOFLAGS:GO111MODULE
$ ./all.bash
ERROR: Cannot find C:\Program Files\Go/bin/go.
Set $GOROOT_BOOTSTRAP to a working Go tree >= Go 1.22.6.

The bash script bootstrap process expects to be able to read go env GOROOT and then use the result as a path. But, Windows Go prints C:\Program Files\Go.

If I manually set GOROOT_BOOTSTRAP to make it so all.bash doesn't need to probe, and I create a copy of "C:\Program Files\Go\bin\go.exe" called "C:\Program Files\Go\bin\go" to get past another error about what it expects the file to be called, then I get a syntax error:

$ ./make.bash
Building Go cmd/dist using /mnt/c/Program Files/Go. (go1.23.3 windows/amd64)
./make.bash: eval: line 197: syntax error near unexpected token `('

With a set -x in the script, it seems that dist is having some translation trouble too:

$ ./all.bash
Building Go cmd/dist using /mnt/c/Program Files/Go. (go1.23.3 windows/amd64)
+++ ./cmd/dist/dist env -p
' set $'GODEBUG=\r' set $'GOENV=off\r' set $'GOFLAGS=\r' set $'GOHOSTARCH=amd64\r' set $'GOHOSTOS=windows\r' set $'GOOS=' set $'GOAMD64=v1\r' set $'GOWORK=off\r' set 'PATH=C:\git\go\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program' 'Files\PowerShell\7\;C:\Program' 'Files\Git\cmd;C:\Program' 'Files\Microsoft' VS 'Code\bin;C:\Program' 'Files\Microsoft' SQL 'Server\Client' 'SDK\ODBC\170\Tools\Binn\;C:\Program' 'Files\Microsoft' SQL 'Server\150\Tools\Binn\;C:\Program' 'Files\dotnet\;C:\Program' Files '(x86)\Incredibuild;C:\Program' Files '(x86)\Windows' 'Kits\10\Windows' Performance 'Toolkit\;C:\.tools\dotnet;C:\.tools\.npm-global;C:\Users\vmadmin\AppData\Local\Microsoft\WindowsApps;C:\Users\vmadmin\.dotnet\tools;C:\Program' 'Files\NuGet;C:\Windows\system32\config\systemprofile\AppData\Local\Microsoft\WindowsApps;;C:\Program' 'Files\Microsoft' Dev Box 'Agen' set 'DIST_UNMODIFIED_PATH=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program' 'Files\PowerShell\7\;C:\Program' 'Files\Git\cmd;C:\Program' 'Files\Microsoft' VS 'Code\bin;C:\Program' 'Files\Microsoft' SQL 'Server\Client' 'SDK\ODBC\170\Tools\Binn\;C:\Program' 'Files\Microsoft' SQL 'Server\150\Tools\Binn\;C:\Program' 'Files\dotnet\;C:\Program' Files '(x86)\Incredibuild;C:\Program' Files '(x86)\Windows' 'Kits\10\Windows' Performance 'Toolkit\;C:\.tools\dotnet;C:\.tools\.npm-global;C:\Users\vmadmin\AppData\Local\Microsoft\WindowsApps;C:\Users\vmadmin\.dotnet\tools;C:\Program' 'Files\NuGet;C:\Windows\system32\config\systemprofile\AppData\Local\Microsoft\WindowsApps;;C:\Program' 'Files\Microsoft' Dev Box 'Agent\Scripts;C:\Program' 'Files\Go\bin;C:'Users\dagood\AppData\Local\Microsoft\WindowsApps;C:\Users\dagood\go\bin
./make.bash: eval: line 198: syntax error near unexpected token `('

Maybe this is solvable, but I've already bypassed the first problem of go.exe env GOROOT path translation, which I already don't know how to fix cleanly. (But I'm still no WSL expert. 😄)

---

As far as workflow goes, it makes a lot more sense to me to install a Linux build of Go and use that inside WSL. You can even cross-build a Windows Go toolset from a Linux Go toolset with GOOS=windows ./make.bash if you need it. (You can have both builds' outputs present in the same clone of the repo.) I tried this out and it seems to work for me.

[bitlux]

Can you install a Linux copy of Go as your bootstrap inside WSL (and does that work)?

Seems to work:

$ wget https://go.dev/dl/go1.23.4.linux-amd64.tar.gz
[...]
$ tar xvf go1.23.4.linux-amd64.tar.gz
[...]
$ mv go /usr/local/
$ /usr/local/go/bin/go version
go version go1.23.4 linux/amd64
$ export PATH=$PATH:/usr/local/go/bin
$ cd /mnt/c/[...]/go/src
$ ./all.bash
Building Go cmd/dist using /usr/local/go. (go1.23.4 linux/amd64)
Building Go toolchain1 using /usr/local/go.
Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
Building Go toolchain2 using go_bootstrap and Go toolchain1.
Building Go toolchain3 using go_bootstrap and Go toolchain2.
Building packages and commands for linux/amd64.

##### Test execution environment.
# GOARCH: amd64
# CPU: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz
# GOOS: linux
# OS Version: Linux 5.15.167.4-microsoft-standard-WSL2 #1 SMP Tue Nov 5 00:21:55 UTC 2024 x86_64

##### Testing packages.
[...]

[seankhliao]

So: using the windows version of go in WSL makes it confused about what the host operating system is. I think the resolution should just be: don't mix tools / OSes like this and use the toolchain native to the environment.