-
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: GOROOT_FINAL doesn't work as expected outside make.bash #17943
Comments
I didn't think GOROOT_FINAL meant anything at all outside of make.bash. /cc @ianlancetaylor @rsc |
I agree that historically |
Not for Go 1.9. Maybe for Go 1.10. |
@rsc I don't think you intended to close this, correct? |
No, I didn't mean to close it. Thanks for reopening. |
Moving the milestone to Unplanned. The idea is fine, and CLs welcome, but nobody is working on this. |
It seems to answer the reported issue. |
Thanks. This is obsolete. Closing. |
When using
make.bash
,GOROOT_FINAL
allows one to build a binary Go distribution under a different directory path then the final install location.One would expect
GOROOT_FINAL
to do the same thing after you ranmake.bash
. E.g. I would expectGOROOT_FINAL=/usr/go go build cmd/gofmt
to produce a gofmt binary that will just work on a machine where Go is installed in/usr/go
. But that is not what it does. The generated gofmt binary will indeed have embedded paths referring to/usr/go
(rather than paths to wherever it was build), however, it will expect the wrongGOROOT
. It will expect theGOROOT
for the build machine rather than the target machine.In other words,
GOROOT_FINAL
is useless outside make.bash.The problem is that binaries use the
GOROOT
defined ingo/src/runtime/internal/sys/zversion.go:/DefaultGoroot/
, which is set bygo tool dist
(so atmake.bash
time). A particular Go build can generate binaries only for one particularGOROOT
at a time.I believe this to be a mistake and it's causing me great pain when working on the SPARC64 port, because the
GOROOT
on my development machine (an macOS machine) is very different than theGOROOT
on the SPARC64 test machines. My workaround is to have two Go trees, and build them with their ownGOROOT
(viaGOROOT_FINAL
for the SPARC64 target), but that makes development painful as I have to copy changes around trees all the time, a very error prone endeavour.I believe
GOROOT_FINAL
should be a target-level configuration (likeGOOS
andGOARCH
), not a build-level configuration.The text was updated successfully, but these errors were encountered: