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: rebuild objects on toolchain mismatch #10702

Closed
rsc opened this issue May 5, 2015 · 2 comments
Closed

cmd/go: rebuild objects on toolchain mismatch #10702

rsc opened this issue May 5, 2015 · 2 comments
Milestone

Comments

@rsc
Copy link
Contributor

rsc commented May 5, 2015

If we can get some indication of the compiler or toolchain version into the build ID hash, it would let people flip between different toolchains with the same GOPATH more easily. In particular, when you flipped it would notice that all the things in $GOROOT/pkg are out of date and rebuild them, whereas today you have to use go install -a or else you get object version conflicts from the compiler and/or linker.

[Please do not close this as a duplicate of some other issue. This one describes what I plan to do.]

@rsc rsc self-assigned this May 5, 2015
@rsc rsc added this to the Go1.5 milestone May 5, 2015
@gopherbot
Copy link

CL https://golang.org/cl/10760 mentions this issue.

@gopherbot
Copy link

CL https://golang.org/cl/10761 mentions this issue.

@rsc rsc closed this as completed in 3ab9ff1 Jun 15, 2015
rsc added a commit that referenced this issue Jun 15, 2015
This CL adds a very long comment explaining how isStale and
the new build IDs work. As part of writing the comment I realized:

// When the go command makes the wrong build decision and does not
// rebuild something it should, users fall back to adding the -a flag.
// Any common use of the -a flag should be considered prima facie evidence
// that isStale is returning an incorrect false result in some important case.
// Bugs reported in the behavior of -a itself should prompt the question
// ``Why is -a being used at all? What bug does that indicate?''

The two uses of -a that are most commonly mentioned in bugs filed
against the go command are:

	go install -a ./...
	go build -tags netgo -a myprog

Both of these commands now do the right thing without needing -a.

The -a exception we introduced in Go 1.4 was for the first form, and
it broke the second form. Again, neither needs -a anymore, so restore
the old, simpler, easier to explain, less surprising meaning used in Go 1.3:
if -a is given, rebuild EVERYTHING.

See the comment for more justification and history.

Summary of recent CLs (to link bugs to this one):

Fixes #3036. Now 'go install ./...' works.
Fixes #6534. Now 'go install ./...' works.
Fixes #8290. Now 'go install ./...' works.
Fixes #9369. Now 'go build -tags netgo myprog' works.
Fixes #10702. Now using one GOPATH with Go 1.5 and Go 1.6 works.
  (Each time you switch, everything needed gets rebuilt.
  Switching from Go 1.4 to Go 1.5 will rebuild properly.
  Switching from Go 1.5 back to Go 1.4 still needs -a when
  invoking the Go 1.4 go command.)

Change-Id: I19f9eb5286efaa50de7c8326602e94604ab572eb
Reviewed-on: https://go-review.googlesource.com/10761
Reviewed-by: Ian Lance Taylor <iant@golang.org>
@golang golang locked and limited conversation to collaborators Jun 25, 2016
@rsc rsc removed their assignment Jun 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants