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

Open
4ad opened this Issue Nov 16, 2016 · 6 comments

Comments

Projects
None yet
6 participants
@4ad
Member

4ad commented Nov 16, 2016

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 ran make.bash. E.g. I would expect GOROOT_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 wrong GOROOT. It will expect the GOROOT 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 in go/src/runtime/internal/sys/zversion.go:/DefaultGoroot/, which is set by go tool dist (so at make.bash time). A particular Go build can generate binaries only for one particular GOROOT 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 the GOROOT on the SPARC64 test machines. My workaround is to have two Go trees, and build them with their own GOROOT (via GOROOT_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 (like GOOS and GOARCH), not a build-level configuration.

@bradfitz

This comment has been minimized.

Member

bradfitz commented Nov 16, 2016

I didn't think GOROOT_FINAL meant anything at all outside of make.bash.

/cc @ianlancetaylor @rsc

@bradfitz bradfitz added this to the Go1.9 milestone Nov 16, 2016

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Nov 16, 2016

I agree that historically GOROOT_FINAL has only ever worked for make.bash. But the suggestion makes sense. It basically means "build a new copy of runtime/internal/sys with an updated GOROOT, and then rebuild every other package". In practice I think it makes the most sense if we can separate the notion of a cache of builds and test results from the current pkg directory layout.

@rsc

This comment has been minimized.

Contributor

rsc commented Jun 5, 2017

Not for Go 1.9. Maybe for Go 1.10.

@rsc rsc modified the milestones: Go1.10, Go1.9 Jun 5, 2017

@rsc rsc closed this Jun 5, 2017

@cespare

This comment has been minimized.

Contributor

cespare commented Jun 5, 2017

@rsc I don't think you intended to close this, correct?

@cespare cespare reopened this Jun 5, 2017

@rsc

This comment has been minimized.

Contributor

rsc commented Jun 12, 2017

No, I didn't mean to close it. Thanks for reopening.

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Dec 6, 2017

Moving the milestone to Unplanned. The idea is fine, and CLs welcome, but nobody is working on this.

@ianlancetaylor ianlancetaylor modified the milestones: Go1.10, Unplanned Dec 6, 2017

@gopherbot gopherbot removed the NeedsDecision label Dec 6, 2017

@4ad 4ad self-assigned this Dec 6, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment