runtime: bad GOROOT in 1.9rc1

[karalabe]

If I unpack Go 1.8.3 to a custom location, I either need to set the correct GOROOT, or it will fail to start.

$ GOROOT=/tmp/go1.8.3 /tmp/go1.8.3/bin/go version
go version go1.8.3 linux/amd64

$ /tmp/go1.8.3/bin/go version
go: cannot find GOROOT directory: /usr/local/go

Go 1.9rc1 does not have this "limitation" any more and even correctly detects its custom GOROOT:

$ /tmp/go1.9rc1/bin/go version
go version go1.9rc1 linux/amd64

$ /tmp/go1.9rc1/bin/go env
[...]
GOROOT="/tmp/go1.9rc1"
[...]

However, the runtime.GOROOT() method still defaults to the GOROOT environmental variable (with the build-path fallback if the env var cannot be found). This is a problem, because it produces runtime issues on systems where Go is not located at the correct path (such as currently Travis).

package main

import (
	"fmt"
	"runtime"
)

func main() {
	fmt.Println(runtime.GOROOT())
}

$ /tmp/go1.9rc1/bin/go run main.go 
/usr/local/go

[karalabe]

We could argue that it works as documented, but until now this scenario was impossible because Go refused to start altogether.

[ianlancetaylor]

I've marked this to be fixed in 1.10. Basically I think it's going to be an unfortunate problem in 1.9.

[fjl]

It would be possible to fix this by setting GOROOT in cmd/go for go run. Maybe that's simple enough for go 1.9?

[ianlancetaylor]

@fjl But that would only fix go run, so we would still be in an inconsistent state for go build or go install. I don't see enough benefit to that to change 1.9 at this point.

[crvv]

Maybe only fixing go run is enough.
After go build or go install, the consistent state between runtime.GOROOT() and $GOROOT can't be guaranteed. The $GOROOT can be deleted after go build.
Besides, runtime.GOROOT() is read from /src/runtime/internal/sys/zversion.go, which is generated during toolchain bootstrapping. I guess fixing this issue for go build is not trivial.

[kevinburke]

FYI - Travis CI is a build tool, and normally you'd add Go 1.9 in the test matrix as a line in the file like this:

- 1.7
- 1.8
- 1.9

The last line currently fails. Users have to (first) discover the problem - compiling packages in the standard library fails - and then Google around until they find the solution, which is to add these additional lines to the configuration:

before_install:
  - export GOROOT=$(go env GOROOT)

It's possible Travis can do some custom work on their end. But at the moment this is going to be a problem for people trying to set up CI for their Go packages.

[pierrre]

See travis-ci/travis-build#1148 + travis-ci/travis-ci#8177
It's fixed in recent gimme versions.

[kevinburke]

Ah, you are correct, thanks!