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: better handling of object mismatch during compilation #6534

Closed
josharian opened this issue Oct 4, 2013 · 10 comments
Closed

cmd/go: better handling of object mismatch during compilation #6534

josharian opened this issue Oct 4, 2013 · 10 comments
Milestone

Comments

@josharian
Copy link
Contributor

What steps will reproduce the problem?

I routinely use a handful of different go toolchains. As a result, I hit variants of
this error pretty frequently when building:

import <...>: object is [darwin amd64 devel +351b6fe0ae36 Tue Sep 24 15:54:48 2013
-0400 X:none] expected [darwin amd64 devel +dd18f98c9aa5 Thu Sep 26 21:35:49 2013 +1000
X:none]

To reproduce quickly:

1. Use one go version (say 1.1.2).
2. go test -i ./...
3. Switch to another go version (say tip).
4. go build ./...


Please provide any additional information below.

It's easy enough to fix the problem; remove the pkg directory, or build with -a.
However, the former is an annoyance and both make builds needlessly longer. (Is there
another option I have failed to find?)

Possible fixes include:

* Put the go toolchain version in the pkg directory (darwin_amd64_1.1.2 or
darwin_amd64_351b6fe0ae36). Optimizes for build speed at the cost of disk space and
directory ugliness.
* Instead of dying on mismatch, just discard the object, recompile, and keep on going.

I'd even suggest that this be considered for Go 1.2, since most users are likely to hit
this (albeit just once) when they upgrade.
@robpike
Copy link
Contributor

robpike commented Oct 4, 2013

Comment 1:

Labels changed: added priority-later, feature, removed priority-triage.

Status changed to Accepted.

@rsc
Copy link
Contributor

rsc commented Nov 27, 2013

Comment 2:

Labels changed: added go1.3maybe.

@rsc
Copy link
Contributor

rsc commented Nov 27, 2013

Comment 3:

Labels changed: removed feature.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 4:

Labels changed: added release-none, removed go1.3maybe.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 5:

Labels changed: added repo-main.

@fraenkel
Copy link
Contributor

The issue raised in #9287 is slightly different. Removing the pkg directory no longer works. I have not found any workaround.

@minux
Copy link
Member

minux commented Dec 12, 2014

Removing the pkg directory really should work.

If removing pkg directory doesn't work, then it means you haven't removed the correct
pkg directory or something else is using older version of go to create a new pkg directory
behind your back. (Josh commented in the original issue that it's probably your editor that
is creating the pkg directory using go1.3.3 for code completion purposes.)

@rsc rsc added this to the Unplanned milestone Apr 10, 2015
@andrewchambers
Copy link

Just a note for others, your text editor may be recreating it when it tries to do code completion with the wrong go version. gosublime confused me for a moment because of this.

@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>
@mikioh mikioh modified the milestones: Go1.5, Unplanned Jun 17, 2015
@golang golang locked and limited conversation to collaborators Jun 25, 2016
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

8 participants