Skip to content
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

Closed
4ad opened this issue Nov 16, 2016 · 8 comments
Closed

cmd/go: GOROOT_FINAL doesn't work as expected outside make.bash #17943

4ad opened this issue Nov 16, 2016 · 8 comments
Labels
help wanted NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@4ad
Copy link
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
Copy link
Contributor

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

/cc @ianlancetaylor @rsc

@bradfitz bradfitz added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Nov 16, 2016
@bradfitz bradfitz added this to the Go1.9 milestone Nov 16, 2016
@ianlancetaylor
Copy link
Member

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
Copy link
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 as completed Jun 5, 2017
@cespare
Copy link
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
Copy link
Contributor

rsc commented Jun 12, 2017

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

@ianlancetaylor
Copy link
Member

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
@ianlancetaylor ianlancetaylor added NeedsFix The path to resolution is known, but the work has not been done. help wanted labels Dec 6, 2017
@gopherbot gopherbot removed the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Dec 6, 2017
@4ad 4ad self-assigned this Dec 6, 2017
@rsc rsc unassigned 4ad Jun 23, 2022
@iwdgo
Copy link
Contributor

iwdgo commented Oct 1, 2024

GOROOT_FINAL was removed in go1.23 ( #62047 ). And go.mod now defines the minimum toolchain which can be set using GOTOOLCHAIN. Suppose building from inside go repository using gotip, build would look like:
PATH='../bin' GOTOOLCHAIN=path go build -trimpath cmd/gofmt
Then moving gofmt output anywhere like /tmp and adding a fake GOROOT produces

/tmp % GOROOT=/usr/go gofmt -h                                       
usage: gofmt [flags] [path ...]
  -cpuprofile string
    	write cpu profile to this file
  -d	display diffs instead of rewriting files
  -e	report all errors (not just the first 10 on different lines)
  -l	list files whose formatting differs from gofmt's
  -r string
    	rewrite rule (e.g., 'a[b:len(a)] -> a[b:]')
  -s	simplify code
  -w	write result to (source) file instead of stdout

It seems to answer the reported issue.

@ianlancetaylor
Copy link
Member

Thanks. This is obsolete. Closing.

@ianlancetaylor ianlancetaylor closed this as not planned Won't fix, can't repro, duplicate, stale Oct 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

7 participants