-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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: go install
with CGO_ENABLED=0 tries to install standard packages, which can fail
#18981
Comments
Your makefile is calling go install, which fails because your user does not have permission to write to that directory. Either use go build to skip writing stdlib packages to a directory the user doesn't own, or build go from source in a directory you don't own. I recommend the second option. https://dave.cheney.net/2014/04/20/how-to-install-multiple-versions-of-go |
wait.... go install is trying to write to $GOROOT, i.e. /usr/local/go? really? I thought |
I agree that a simple |
If you set https://dave.cheney.net/2015/08/22/cross-compilation-with-go-1-5, see comparison of go build vs go install. |
Okay, then. So my immediately problem is solved. Thank you, Dave, for pointing the surprising difference between @ianlancetaylor This is really pretty surprising behavior; I wouldn't have expected that CGO_ENABLED=0 would require a rebuild of the entire standard lib. If you want to leave the ticket open as a bug, that's okay with me. I'm also okay with closing it, at your discretion. Dave's cross-compilation post makes it clear for cross-compilation, but its not clear to me that setting CGO_ENABLED=0 is, or should be thought of, the same as cross-compiling.
|
Standard library builds (e.g. |
(tongue in cheek...) perhaps $GOROOT==$GOPATH could mean "write my standard libs" under GOPATH. |
Setting That said, it does seem wrong that |
go install
with CGO_ENABLED=0 tries to install standard packages, which can fail
Ian, does that argument extend to cross compilation? That's the place most
users hit this issue.
…On Wed, 8 Feb 2017, 07:33 Ian Lance Taylor ***@***.***> wrote:
Setting CGO_ENABLED=0 does not require rebuilding the entire standard
library, but it does require rebuilding the standard library packages that
use cgo. Those packages are: net, os/user, crypto/x509.
That said, it does seem wrong that go install tries to install a standard
library package in this case. If the package is not mentioned on the
command line, it seems to me that it should be built but not installed.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#18981 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAAcA2W8umf9_BB9Pfh2H8x1CIPIYzvUks5raNUUgaJpZM4L5xMh>
.
|
My feeling right now is that if you are using a release, then running Happy to hear counter-arguments. |
That would be wonderful if that was the outcome of this ticket, the
"official binary + cross compile + go install" story is the last remaining
hurdle to Go developers having a seamless cross compilation experience with
our official builds.
…On Wed, Feb 8, 2017 at 7:51 AM, Ian Lance Taylor ***@***.***> wrote:
My feeling right now is that if you are using a release, then running go
install without explicitly mentioning any standard library package should
not attempt to install any standard library package. Clearly if you run go
install std or go install net then it should install the standard library
package (if it is out of date). But if you don't do that, I don't think go
install should be trying to write files into GOROOT.
Happy to hear counter-arguments.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#18981 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAAcAys1VIUMFRjtrCS5AQseaeynhzgNks5raNlngaJpZM4L5xMh>
.
|
Note, in our case, this occurred with |
Strongly agree with @davecheney. In https://gokrazy.github.io/, a hurdle which multiple users have stumbled over is that Go installations from installers and distribution packages will fail cross-compilation with a “permission denied” error in the standard library. I.e., people run something like I think many of us are blind to that issue because we install Go from source. End users typically don’t. |
Work on better caching will fix this. I have a prototype. Not for Go 1.9 but probably for Go 1.10. |
Change https://golang.org/cl/75850 mentions this issue: |
It was writing to stdlib packages net, x/crypto, etc. and failing when it didn't have write access to them (which it often shouldn't) Fixes issue #941 Explained in golang issue: golang/go#18981 (fixed in develop/1.10)
It was writing to stdlib packages net, x/crypto, etc. and failing when it didn't have write access to them (which it often shouldn't) Fixes issue #941 Explained in golang issue: golang/go#18981 (fixed in develop/1.10)
This works around golang/go#18981 until that fix makes it into an official release.
This gets us a fixed 'CGO_ENABLED=0 go install' [1,2] and avoids 1.8 (which is no longer supported upstream now that 1.10 has been released [3]). I've also dropped the version information from the build comment (it's mentioned just before in the "Requirements" section) to DRY things up a bit. [1]: golang/go#18981 [2]: golang/go@8f70e1f8a91 [3]: https://golang.org/doc/devel/release.html#policy
GOBIN (documented in [1]) defaults to DIR/bin, but it's a configurable variable in its own right. The old logic was just looking at GOPATH, though, and not respecting GOBIN. This commit updates our install target to lean on Go's build caching (instead of using Make's dependency trees) to ensure a fresh-enough build lands in the appropriate directory. This approach relies on Go 1.10+ to avoid [2], but we've required Go 1.10+ since b859ebf (Documentation/development: Bump minimum Go version to 1.10, 2018-04-03, kubernetes-retired#955). For the build documentation, I've switched to 'go env GOPATH' to get the (platform-specific [1]) default value when the environment variable is not set. And I've used cut [3] (instead of the awk [4] the Makefile used to use) to pull out the first component of GOPATH. Both are in POSIX, but cut is a simpler tool for this particular problem. [1]: https://golang.org/cmd/go/#hdr-GOPATH_environment_variable [2]: golang/go#18981 [3]: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cut.html [4]: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/awk.html
GOBIN (documented in [1]) defaults to DIR/bin, but it's a configurable variable in its own right. The old logic was just looking at GOPATH, though, and not respecting GOBIN. This commit updates our install target to lean on Go's build caching (instead of using Make's dependency trees) to ensure a fresh-enough build lands in the appropriate directory. This approach relies on Go 1.10+ to avoid [2], but we've required Go 1.10+ since b859ebf (Documentation/development: Bump minimum Go version to 1.10, 2018-04-03, #955). For the build documentation, I've switched to 'go env GOPATH' to get the (platform-specific [1]) default value when the environment variable is not set. And I've used cut [3] (instead of the awk [4] the Makefile used to use) to pull out the first component of GOPATH. Both are in POSIX, but cut is a simpler tool for this particular problem. [1]: https://golang.org/cmd/go/#hdr-GOPATH_environment_variable [2]: golang/go#18981 [3]: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cut.html [4]: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/awk.html
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?[jaten@biggie tmp]$ go version
go version go1.8rc3 linux/amd64 ## also happens on go1.7.4
[jaten@biggie tmp]$
What operating system and processor architecture are you using (
go env
)?[jaten@biggie tmp]$ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/jaten/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build885638224=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="0"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
[jaten@biggie tmp]$
What did you do?
I ran make for https://github.com/glycerine/vhaline
Makefile does go install on the library github.com/glycerine/vhaline/vhaline and then on a test executable; github.com/glycerine/vhaline/cmd/vhaline
What did you expect to see?
successful build. build is successful without CGO_ENABLED=0
What did you see instead?
The text was updated successfully, but these errors were encountered: