Open dsnet opened 5 years ago
The bootstrapping code for go1.12
is not really aware of module mode. Does this occur with a clone of the go
repository at head?
Nope. Replace curl -s -L https://dl.google.com/go/go1.12.7.src.tar.gz | tar -zxf -
with git clone https://go.googlesource.com/go
and the problem goes away.
Ok. In that case, I don't think we need to backport a fix. (I did a bunch of work to make the go
repo itself work in module mode at the start of the 1.13 cycle, so it's not surprising that it doesn't work well in 1.12.7.) I'm going to close this issue as fixed, but please do reopen if I've missed an important use-case that it impacts.
Re-opening. This is still an issue at tip if the go.mod
file is sufficiently complicated (e.g., has a require statement).
Repro steps:
go mod init github.com/user/project
echo "require github.com/golang/protobuf v1.2.1-0.20190620192300-1ee46dfd80dd" >> go.mod
mkdir -p sub/sub/sub && cd sub/sub/sub
git clone https://go.googlesource.com/go
cd go/src
./make.bash
I think was exposed to this issue (or a variation of it) when building Go 1.21.4 in a Yocto environment, but in my case it seems like it's triggered by a go.work
file in the root of the project instead of a go.mod
:
build/ # Yocto build dir.
tmp-arm-glibc/
work/
<target>
go/ # Go 1.21.4 source checkout and build dir in Yocto.
...
tools/ # Internal tools module.
go.mod
go.work # Only used to include the ./tools directory for IDE functionality in VSCode.
Using
go1.12
. That isGOROOT_BOOTSTRAP
is set to some Go toolchain with module support.Steps to reproduce:
It seems odd that
./make.bash
should care whether ago.mod
file exists in any directory above it.\cc @bcmills