Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: still need to set GOROOT with go1.9beta2 #20997

Closed
markus-oberhumer opened this issue Jul 13, 2017 · 11 comments
Closed

cmd/go: still need to set GOROOT with go1.9beta2 #20997

markus-oberhumer opened this issue Jul 13, 2017 · 11 comments

Comments

@markus-oberhumer
Copy link

I had hoped that now that issue #18678 is resolved I never have to think about GOROOT again. That does not seem the case, though.

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

go1.9beta2.linux-amd64 running on Fedora 26

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

$ unset GOROOT
$ /opt/cc-i386-linux/go/golang/go1.9beta2.linux-amd64/bin/go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/mfx/go"
GORACE=""
GOROOT="/opt/cc-i386-linux/go/golang/go1.9beta2.linux-amd64"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="/usr/bin/gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build312405700=/tmp/go-build -gno-record-gcc-switches"
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"

What did you do?

$ cat hello.go
package main

import "fmt"

func main() {
        fmt.Println("Hello go")
}
$ unset GOROOT
$ /opt/cc-i386-linux/go/golang/go1.9beta2.linux-amd64/bin/go env | grep GOROOT
GOROOT="/opt/cc-i386-linux/go/golang/go1.9beta2.linux-amd64"

As you can see GOROOT is set correctly by go env.

$ unset GOROOT
$ /opt/cc-i386-linux/go/golang/go1.9beta2.linux-amd64/bin/go build hello.go 
hello.go:3:8: cannot find package "fmt" in any of:
        /usr/local/go/src/fmt (from $GOROOT)
        /home/mfx/go/src/fmt (from $GOPATH)
package main
        imports runtime: cannot find package "runtime" in any of:
        /usr/local/go/src/runtime (from $GOROOT)
        /home/mfx/go/src/runtime (from $GOPATH)

But it seems go build has a different GOROOT /usr/local/go.

@markus-oberhumer
Copy link
Author

Somewhat related, it seems that GOTOOLDIR is not automatically set.

$ unset GOROOT GOTOOLDIR
$ /opt/cc-i386-linux/go/golang/go1.9beta2.linux-amd64/bin/go env | egrep 'GOROOT|GOTOOLDIR'
GOROOT="/opt/cc-i386-linux/go/golang/go1.9beta2.linux-amd64"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"

Should I file a new issue for GOTOOLDIR ?

@markus-oberhumer markus-oberhumer changed the title Still need to set GOROOT with go1.9beta2 cmd/go: still need to set GOROOT with go1.9beta2 Jul 13, 2017
@ianlancetaylor
Copy link
Contributor

Please show us the output of go build -x.

@ianlancetaylor
Copy link
Contributor

The GOTOOLDIR problem is interesting, and may be related. GOTOOLDIR is computed based on the value returned by runtime.GOROOT(), which is not the same as the GOROOT value that the go tool computes after it starts up.

@markus-oberhumer
Copy link
Author

There's not much extra info that go build -x does provide. And as I'm just using the public version from https://storage.googleapis.com/golang/go1.9beta2.linux-amd64.tar.gz you should be able to reproduce this issue.

$ env -i /opt/cc-i386-linux/go/golang/go1.9beta2.linux-amd64/bin/go env | egrep 'GOROOT|GOTOOLDIR'                                                                 
GOROOT="/opt/cc-i386-linux/go/golang/go1.9beta2.linux-amd64"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
$ env -i /opt/cc-i386-linux/go/golang/go1.9beta2.linux-amd64/bin/go build -x hello.go
WORK=/tmp/go-build254896712
hello.go:3:8: cannot find package "fmt" in any of:
        /usr/local/go/src/fmt (from $GOROOT)
        ($GOPATH not set. For more details see: 'go help gopath')
package main
        imports runtime: cannot find package "runtime" in any of:
        /usr/local/go/src/runtime (from $GOROOT)
        ($GOPATH not set. For more details see: 'go help gopath')

@ianlancetaylor
Copy link
Contributor

You're right, I can recreate the problem. It's easy to recreate by building Go, and then moving the entire GOROOT directory elsewhere. Our tests don't work because we don't move the GOROOT directory--we don't want to do that, because it would break any other tests running at the same time.

@bradfitz Any suggestions for how to test this? The best I can think of is to copy GOROOT, remove GOROOT/pkg, run make.bash, move the copied GOROOT elsewhere, and check that it works. But that will be very slow and I'm not even sure where to put such a test.

@gopherbot
Copy link

CL https://golang.org/cl/48550 mentions this issue.

@bradfitz
Copy link
Contributor

Our tests don't work because we don't move the GOROOT directory--we don't want to do that, because it would break any other tests running at the same time.

Only one cmd/dist/test test runs at a time per builder machines. (A single build might have it tests sharded out over 6-8 machines)

And if one fails, that buildlet ("machine") is never reused. So the test can clean up after itself (rename the goroot back to its original name) and any future tests would still work.

So the src/cmd/dist/test.go test would do something like:

  • rename $GOROOT to $GOROOT+"-moved"
  • run the test that the go tool works
  • rename $GOROOT+"-moved" back to the original $GOROOT

@bradfitz
Copy link
Contributor

... and if you want to not mess with user machines, you can do it only if testenv.Builder() != ""

@bradfitz
Copy link
Contributor

Oh, in dist we can't depend on testenv, but looks like it already uses os.Getenv("GO_BUILDER_NAME") in a few places.

@ianlancetaylor
Copy link
Contributor

Thanks. Added a test to the CL.

@markus-oberhumer
Copy link
Author

Thanks!

@golang golang locked and limited conversation to collaborators Jul 15, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants