FS#38597 - [go] $GOROOT is not needed

Attached to Project: Community Packages
Opened by Pierre Durand (Pierrre) - Tuesday, 21 January 2014, 10:56 GMT
Last edited by Alexander F. Rødseth (xyproto) - Wednesday, 26 February 2014, 16:19 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Alexander F. Rødseth (xyproto)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
http://dave.cheney.net/2013/06/14/you-dont-need-to-set-goroot-really
The environment variable $GOROOT is not needed (defined in /etc/profile.d/go.sh)

This task depends upon

Closed by  Alexander F. Rødseth (xyproto)
Wednesday, 26 February 2014, 16:19 GMT
Reason for closing:  Fixed
Additional comments about closing:  GOROOT is not set by the go package. This was fixed. The re-opening seems to be "not a bug".
Comment by Alexander F. Rødseth (xyproto) - Wednesday, 22 January 2014, 16:44 GMT
Hi, thanks for reporting. Setting GOROOT is optional, but I will consider removing it from the go package.
Comment by Pierre Durand (Pierrre) - Wednesday, 22 January 2014, 16:52 GMT
If you have multiple Go versions installed, the GOROOT variable breaks the "custom" installation.
I have the "tip" version installed (for test), and I must unset GOROOT in order to make it work.
Comment by Alexander F. Rødseth (xyproto) - Thursday, 23 January 2014, 09:45 GMT
I see. I will fix this.
Comment by Wu Ke (ngukho) - Friday, 14 February 2014, 01:28 GMT
godoc still requires GOROOT to properly find libraries. In go-2:1.2-2, one gets the following error because GOROOT is not set and godoc defaults it to /usr/local/go:
$ godoc io
2014/02/13 03:47:46 open /usr/local/go/src/pkg/io: no such file or directory
Comment by Alexander F. Rødseth (xyproto) - Friday, 14 February 2014, 12:04 GMT
Thanks for re-opening.

After having receieved pointers to this link in the past (http://dave.cheney.net/2013/06/14/you-dont-need-to-set-goroot-really) together with requests for removing the GOROOT setting, I'm surprised that it should be set by the go package. I'm currently asking #go-nuts what they think. So far one person thinks that GOROOT_FINAL is should be set instead. I'll investigate some more.
Comment by Alexander F. Rødseth (xyproto) - Friday, 14 February 2014, 12:16 GMT
Someone suggested that the godoc problem might be because an old binary was lying around.

What does

which godoc

and

pacman -Qo `which godoc`

say?
Comment by Pierre Durand (Pierrre) - Friday, 14 February 2014, 15:43 GMT Comment by Pierre Durand (Pierrre) - Friday, 14 February 2014, 15:54 GMT
When you install manually godoc (go get code.google.com/p/go.tools/cmd/godoc),
there is a special case https://code.google.com/p/go/source/browse/src/cmd/go/pkg.go?name=release-branch.go1.2#312
It's installed in $GOROOT_FINAL/bin instead of $GOPATH/bin
Comment by Jesus Alvarez (demizer) - Saturday, 15 February 2014, 09:54 GMT
I too get an error when using godoc. A workaround is to use

godoc -goroot="/usr/lib/go"

I have not installed godoc manually.
Comment by Wu Ke (ngukho) - Saturday, 15 February 2014, 20:13 GMT
$ which godoc
/usr/bin/godoc
$ pacman -Qo `which godoc`
/usr/bin/godoc is owned by go 2:1.2-2
Comment by Alexander F. Rødseth (xyproto) - Tuesday, 18 February 2014, 11:18 GMT
Since removing GOROOT caused problems (despite several people saying it should not cause problems), I will update the package and re-add GOROOT.
Comment by Pierre Durand (Pierrre) - Tuesday, 18 February 2014, 12:29 GMT
If I compile Golang myself (http://golang.org/doc/install/source), there is no problem with godoc.
Comment by Alexander F. Rødseth (xyproto) - Tuesday, 18 February 2014, 19:12 GMT
Unfortunately, compiling and installing go in the home directory, as a regular user, is not a comparable situation to packaging go as a system wide package.

I will re-add GOROOT and see if it makes godoc work again.
Comment by Pierre Durand (Pierrre) - Saturday, 22 February 2014, 19:41 GMT Comment by Alexander F. Rødseth (xyproto) - Monday, 24 February 2014, 14:10 GMT
Pierre Durand, if godoc fails without GOROOT being set, why is it of your opinion (since you refer to the opinion of Dave Cheney) that it is not needed?
Comment by Pierre Durand (Pierrre) - Monday, 24 February 2014, 14:28 GMT
I don't know.
"export GOROOT_FINAL=/usr/lib/go" (in PKGBUILD) should work.
Comment by Alexander F. Rødseth (xyproto) - Monday, 24 February 2014, 14:38 GMT
export GOROOT_FINAL=/usr/lib/go is already present in the PKGBUILD. https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/go#n44

Reportedly, godoc worked when GOROOT was still set in /etc/profile.d/go.sh.

If this is a problem with godoc or not, I don't know, but if adding GOROOT solves a problem and has no negative consequences, not adding GOROOT back would be curious choice.
Comment by Pierre Durand (Pierrre) - Monday, 24 February 2014, 14:47 GMT
Do you have a build log?

If I compile Go with GOROOT=/tmp I get this at the end of the build:

"The binaries expect /home/pierre/Logiciels/go to be copied or moved to /tmp"
Comment by Pierre Durand (Pierrre) - Monday, 24 February 2014, 14:53 GMT
OK OK OK I understand now!

You use a pre compiled Go (http://go.googlecode.com/files/go1.2.linux-amd64.tar.gz)

I think GOROOT_FINAL is only useful/usable if you build Go from source! :)
Comment by Alexander F. Rødseth (xyproto) - Monday, 24 February 2014, 18:40 GMT
Unless I'm missing something major, Go, as packaged in the "go" package, *is* built from source. And GOROOT_FINAL is set and used in the process.

Are there objections to adding /etc/profile.d/go.sh back to the go package, so that it sets GOROOT, so that godoc starts working again?

I wish to make sure the go package is packaged as correctly as possible, but if a good default setting can fix a commonly used tool, I think it's a worthwhile trade-off.
Comment by Pierre Durand (Pierrre) - Monday, 24 February 2014, 18:51 GMT
Not really, you use the binary distribution (and you compile it).

http://golang.org/doc/install
"Installing to a custom location"
The Go binary distributions assume they will be installed in /usr/local/go (or c:\Go under Windows), but it is possible to install the Go tools to a different location. In this case you must set the GOROOT environment variable to point to the directory in which it was installed.
For example, if you installed Go to your home directory you should add the following commands to $HOME/.profile:
export GOROOT=$HOME/go
export PATH=$PATH:$GOROOT/bin
Note: GOROOT must be set only when installing to a custom location.

Actually, if you want to really build the package from source, you need to clone https://code.google.com/p/go
http://golang.org/doc/install/source
Comment by Alexander F. Rødseth (xyproto) - Monday, 24 February 2014, 19:00 GMT
The sources is included in go1.2.linux-amd64.tar.gz, and are being used for compiling Go. So, I believe "You use a pre compiled Go" is not correct.

But by all means, fetching the code with mercurial, from the correct release tag, may be a favorable approach.

In any case, the documentation you linked to seems clear to me. When go is not installed in /usr/local (not normally used by Arch Linux packages), GOROOT should be set.
Comment by Pierre Durand (Pierrre) - Monday, 24 February 2014, 19:06 GMT
Yes, GOROOT should be set if you use the binary distribution and Go is not installed in /usr/local.

Are you sure the "godoc" binary is built when you run make.bash?
I think it's not compiled, and you use the precompiled binary.
Comment by Alexander F. Rødseth (xyproto) - Monday, 24 February 2014, 19:27 GMT
I will investigate. I'll try switching over to building directly from sources from mercurial as well. Thanks for the input.
Comment by Pierre Durand (Pierrre) - Monday, 24 February 2014, 19:37 GMT
If godoc is currently broken, you should revert back (set GOROOT)
Comment by Pierre Durand (Pierrre) - Monday, 24 February 2014, 19:51 GMT
I was right!
If you run make.bash form the precompiled go distribution, godoc is NOT build! :)
GOROOT_FINAL is not used for godoc.

Steps:
- download and extract go 1.2 precompiled distribution
- remove binaries in "bin" (go, gofmt, godoc)
- run "./make.bash" in "src"
- only go and gofmt are built in "bin"
Comment by Pierre Durand (Pierrre) - Monday, 24 February 2014, 20:26 GMT
Building Go from source is tricky.

https://code.google.com/p/go/source/browse/src/cmd/go/pkg.go?name=go1.2#299
There is a special case when you run "go get code.google.com/p/go.tools/cmd/godoc".
It is installed in GOROOT/bin instead of GOPATH/bin.
cover and vet tools are installed in GOROOT/pkg/tool

You must embed this tools it the "go" archlinux package, because the user can't install them in GOROOT_FINAL (owned by the root user)
Comment by Alexander F. Rødseth (xyproto) - Monday, 24 February 2014, 21:10 GMT
Nicely figured out about godoc, thanks! Then exporting GOROOT from /etc/profile.d/go.sh probably isn't needed at all.

Building from the mercurial sources seems to work fine. I'm currently trying to find the right place to put "go get" for the various needed tools (and find the correct environment variables).
Comment by Pierre Durand (Pierrre) - Tuesday, 25 February 2014, 09:01 GMT
If you want to use "go get", you have to set GOPATH.
When you use "go get", binaries are installed in $GOPATH/bin (except vet, cover and godoc).

I think GOARCH is not needed in PKGBUILD (I don't use it when I compile Go from source, or install libraries).
You should use "any" for the package's arch.
(I've successfully built Go on ArchLinux ARM)
Comment by Alexander F. Rødseth (xyproto) - Wednesday, 26 February 2014, 09:35 GMT
No, using "any" would not be correct. It is for the target architecture of the binary packages, not which architectures it can be built for. Also, Arch Linux ARM specifically does not want Arch Linux to make any changes to any packages to help them out. They have their own system of adopting i686/x86_64/arm* packages.

Since this issue is about GOROOT, and it has been concluded that it indeed does not need to be set (the problem was with godoc), and since the current go package does not set GOROOT, I'll just close this issue.

Loading...