cmd/go: include GOROOT in linkActionID hash #22475
Labels
FrozenDueToAge
NeedsDecision
Feedback is required from experts, contributors, and/or the community before a change can be made.
release-blocker
Milestone
Going to comment out the use of GOROOT in the linkActionID hash to try to make progress on CL 73216. We need to figure out what to do about GOROOT and the linker. all.bash gets a bit fussy when GOROOT changes unexpectedly.
The more general problem is that if you build a distribution with GOROOT=/usr/local/go and then move it to /home/gopher/go and run it from there, cmd/go will decide (correctly) that all the commands are stale, because it knows that if they were rebuilt from their current sources and location they would come out different - they'd use GOROOT=/home/gopher/go instead of /usr/local/go.
There are two uses of GOROOT in the result. The first is @crawshaw's recent GOROOT override, which I think is probably wrong in some way (#22155), but the second is the source file names. I think we do want binaries built with Go from /home/gopher/go to report that Printf is in /home/gopher/go/src/fmt/print.go in their debug information. We could decide to just say "go" instead of "/home/gopher/go" I suppose.
The go command doesn't check cmd/* for staleness in ordinary builds. This only really affects a few tests during run.bash. So maybe we should fix the tests and not worry about the general case.
This issue is to track deciding what to do and uncommenting the GOROOT code in linkActionID.
The text was updated successfully, but these errors were encountered: