go: x/vgo: VGOROOT is not a Go 1.10 source tree

What version of Go are you using (go version)?

go version go1.10.1 linux/amd64on Arch installed with pacman.

Does this issue reproduce with the latest release?

I only with tried this version.

What operating system and processor architecture are you using (go env)?

Arch Linux 64bit (up-to-date)

go env
GOARCH="amd64"
GOBIN="/home/alexandre/go/bin"
GOCACHE="/home/alexandre/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/alexandre/go"
GORACE=""
GOROOT="/usr/lib/go"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build664545153=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I installed vgo with go get -u golang.org/x/vgo. I run vgo -h

What did you expect to see?

I was expecting some help from the command.

What did you see instead?

I have a error message which I don’t really understand: vgo requires Go 1.10 but VGOROOT=/usr/lib/go is not a Go 1.10 source tree

No matter, from where I try to run the command or if I set the VGOROOT to a directory inside the Go tree.

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 18 (2 by maintainers)

Most upvoted comments

Here is the line that causes vgo to fail if $GOROOT/api/go1.10.txt is missing: https://github.com/golang/vgo/blob/7373d8bcff7c682d097eabe987299681fa40a9cf/vendor/cmd/go/internal/cfg/cfg.go#L126

Right, the missing file is easy enough to fix. vgo should probably use go version to check that, not testing a file. Having distributions ship that file might make sense but afaict from a brief and speculative review that file looks like it’s something that we can only reasonably expect to live in the source tree, not in installs. So the main question is why vgo wants a go source tree and isn’t satisfied with a go install, so we can refactor that problem away.

Yes but why doen’t Arch include these files? Does everyone that want to try vgo install from source? The installers from golang.org works right? Why mess with them? This is so like Arch, I have run it for ages but there is always stuff like this from time to time that is totally not needed…

Needed for tests usually is the operating word I think. Why do this at all? It only makes it fragile and prone to breakage to modify stuff like this which was to be proven by this very issue.

Again this is why people get tired of package managers and downstream “tweaks”…

Don’t get me wrong, Arch is usually doing a great packaging job and it works very well given the pace of updates but it has been a mess sometimes such as the whole Haskell explosion that at least used to happen from time to time.

This didn’t have to happen and it can be fixed but upstream needs to know for that to occur.

On Mon, Apr 16, 2018, 17:14 Nathan Bass notifications@github.com wrote:

@dahankzter https://github.com/dahankzter this isn’t specific to Arch, go run Debian and the exact same thing will occur… The files that vgo is looking for that these distros are leaving out are only needed for tests usually, the requirement that vgo be able to find that file is a change in the actual install requirements (IE: now those files are needed for more than just tests); you can hardly blame the Arch (or debian) maintainers for not foreseeing that test files would be needed in the real world suddenly when they weren’t before.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/golang/go/issues/24773#issuecomment-381639457, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKcU8ZdPhnd9m-0k4WjIxSS245d3T5tks5tpLU8gaJpZM4TMUkF .

I’m not familiar with pacman. Are you sure the package you installed includes the Go 1.10 source tree? If it’s a binary-only installation, that might not be sufficient.