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

[alexandrestein]

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.

[bcmills]

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.

[alexandrestein]

Thanks.

I installed go from sources and when I hit the same command vgo -h I got:

Go is a tool for managing Go source code.

This is vgo, an experimental go command with support for package versioning.
Even though you are invoking it as vgo, most of the messages printed will
still say "go", not "vgo". Sorry.

....

I believe this is the correct message.

Should I make a bug report to the package maintainer?
Or source installation is just mandatory?

[IngCr3at1on]

grr, I did not save that comment yet (github, sorry y'all)...

this is an issue with https://github.com/golang/vgo/blob/master/vendor/cmd/go/internal/cfg/cfg.go#L126

basically arch and other distros don't include the file that is being checked for to confirm the go version: https://www.archlinux.org/packages/extra/x86_64/go/

(this is also an issue with debian, saw a conversation about it the other day but can't find it now)...

---

It would be nice if we could find a way to resolve this that didn't require all distros change their package method OR everyone install from source.

---

a quick and dirty fix (just tested in arch)

sudo mkdir /usr/lib/go/api
sudo touch /usr/lib/go/api/go1.10.txt

[bcmills]

Since vgo is still experimental, I think source installation is still required at this point (I'm still a bit fuzzy on the reasons).

When/if it gets merged back into the go command, I would expect that either it will no longer require the Go source tree, or distro packagers will adjust accordingly.

[alexandrestein]

Thank you for all the informations.
I don't know if the issue needs to be closed or not.

I let you close it if you want to.

[dahankzter]

Did you report this upstream to Arch?

[alexandrestein]

As @bcmills pointed, vgo is still experimental and the true reason why we need the source tree is fogy.
In this context I don't expect that distribution maintainers have to take care of this.

For me, at this point if you really want to use or try vgo you must install go from source.

[dahankzter]

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....

[IngCr3at1on]

@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.

[dahankzter]

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 [e-mail] 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
.

[klingtnet]

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

[ddevault]

As @bcmills pointed, vgo is still experimental and the true reason why we need the source tree is fogy.
In this context I don't expect that distribution maintainers have to take care of this.

@alexandreStein can you explain this "true reason"? It'll need to be addressed eventually.

[alexandrestein]

I can't. :smile:
I simply relayed the message of @bcmills which is labeled as member.

I actually switched to installation from source and I did not made any further investigations since.

But apparently @klingtnet did and found that the issue was caused by a missing file.

[ddevault]

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.

[IngCr3at1on]

I don't think it does require the source tree, I've been using it on arch without a full source tree (just the above fix) without issues; unless someone can confirm that something else in the source tree is required I believe the only refactoring should really be implementing the version check as @SirCmpwn described.

[klingtnet]

I've been using it on arch without a full source tree (just the above fix) without issues

Can confirm this.

[alexandrestein]

I've been using it on arch without a full source tree (just the above fix) without issues

Same for me after I have copied the api directory into GOROOT and reinstall go with pacman.
Then vgo seems to be working.

[ulm0]

Happened to me on Xubuntu 16.04.4, @IngCr3at1on fix solved my problem.