-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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: With Go 1.4, cannot statically link a program which imports net #9344
Comments
Working as intended. In released version of go, go build/install -a std will not try to |
So is the above static linking behaviour therefore a bug in go 1.3.x? |
@minux, just to make it clear, do I understand correctly that using |
To clarify, go install/build -a std won't do anything for standard packages |
@minux: when you say "a released version of Go" are you referring to 1.3.x as well as 1.4?? |
This change in behavior only applies to 1.4. |
I see, thanks. Programs which import the net package and need to be statically linked cannot migrate to 1.4. Is there some reason, in principle, why such static linking cannot be supported in 1.4.x or does commit 8c3005c preclude such a solution? |
@glyn, if I understood correctly (@minux did not address my question directly), before 1.3, when you performed the encantation being discussed, a part of the Go's stdlib has been silently rebuilt and replaced -- most of folks did not notice it because most have Go built from the source and installed somewhere under ~. Since this behaviour clearly fails with system-wide Go installs (some people do use The solution is just to build and install another instalce of the Go toolchain and use it via custom $GOROOT where applicable. IOW, building fully static programs on Linux did not ever do The Right Thing. I think it might be sensible to file a wishlist bug asking to somehow make stdlib support both behaviours out of the box. Dunno if it's feasible to implement. |
@glyn, I mean a custom build of the Go toolchain done with CGO_ENABLED=0 (and maybe |
No no no. You don't need to set GOROOT, ever. Please see my blog On Thu, Dec 18, 2014 at 6:57 AM, Konstantin Khomoutov <
|
2014-12-17 22:57 GMT+03:00 Konstantin Khomoutov notifications@github.com:
This is not true. I'm use go from package system (that install it in Vasiliy Tolstov, |
@iand i say for go 1.3 not for 1.4. |
@vtolstov the behaviour of go install -a was changed in 1.4 so it doesn't recompile the std library if you are using a release version of Go. This issue looks like an unfortunate side effect of that change. There seems to be no way to recompile the standard library in a release version of Go without recompiling all of Go from source. While that's not onerous for those who regularly use the source version it will cause problems for those who want or need to use pre-packaged versions. This discussion from golang-dev is relevant: https://groups.google.com/d/msg/golang-dev/2ZUi792oztM/Q0rg_DkF5HMJ One solution might be to skip building the std library except when the -tags argument is used and any of the specified tags are used by the std library. |
See #9369. |
I simply didn't notice this issue when I opened 9369. I'll leave them both open for now since there are useful comments on both. |
Fair enough. |
Work around: use -installsuffix. CGO_ENABLED=0 go build -a -installsuffix cgo Edited to add: while this workaround was useful for old versions of Go, it is completely unnecessary for Go 1.10 and later. If you have been using it, you can stop. |
I don't think we are going to do anything--using -installsuffix fixes the problem. |
Hi. It should be well documented, thanks for the effort. |
Previously netdog had to be built with Go 1.3 to ensure it was statically linked. With a workaround to Go bug 9344[1], this is now achievable with Go 1.4. [1]: golang/go#9344 [#86913170] Signed-off-by: Chris Brown <cbrown@pivotal.io>
I'm really puzzled about this. The primary reason I built my app was for static linking which I thought was the default behaviour and now I find that forever more I'll need to use what seems like a kludge to compile: CGO_ENABLED=0 go build -a -installsuffix cgo -ldflags '-s' src/myapp/myapp.go I'm using Go 1.5.1 |
If you want static compilation always then I recommend installing Go from env CGO_ENABLED=0 ./all.bash That will disable cgo permanently. On Tue, Oct 20, 2015 at 4:55 PM, dukedougal notifications@github.com
|
Go 1.5.1 LGTM |
So no need to have glibc installed for example
While it sucks to switch to an unmaintained project, we don't lose anything from this switch, and we gain a killer feature: gomacs can be staticly compiled (and it is with default settings). Glisp's api also provides more idiomatic Go, and it seems to be a tad quicker, too.
In Go 1.3.x, it was possible to statically link a program which imports the net package. This is important when building programs for cut-down environments, for example busybox.
The problem can be reproduced on Ubuntu as reported by Vasiliy Tolstov:
It is possible to statically link this program in Go 1.3.x by issuing:
but with Go 1.4, the same technique creates the following runtime dependencies:
The text was updated successfully, but these errors were encountered: