cmd/go: object mismatch error switching between 1.6beta2 and rc1 #14176

danp · 2016-02-01T18:06:41Z

It's my understanding that changing Go versions should rebuild package objects as necessary. Today, I got an error like this:

import /Users/dan.peterson/Projects/go/pkg/darwin_amd64/github.com/sclasen/swfsm/migrator.a: object is [darwin amd64 go1.6beta2 X:none] expected [darwin amd64 go1.6rc1 X:none]

Put together a repro:

rebuild-issue % pwd
/Users/dan.peterson/Projects/go/src/github.com/dpiddy/rebuild-issue
rebuild-issue % go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/dan.peterson/Projects/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GO15VENDOREXPERIMENT="1"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fno-common"
CXX="clang++"
CGO_ENABLED="1"
rebuild-issue % rm -rf /usr/local/go        
rebuild-issue % rm -rf $GOPATH/pkg 
rebuild-issue % curl -s https://storage.googleapis.com/golang/go1.6beta2.darwin-amd64.tar.gz | tar -C /usr/local -zxf -
rebuild-issue % go install -x ./...                                                                                 
WORK=/var/folders/5b/rh45nd3n5sz5phl9s2kx8vwhng20hp/T/go-build805043701
mkdir -p $WORK/github.com/dpiddy/rebuild-issue/foo/_obj/
mkdir -p $WORK/github.com/dpiddy/rebuild-issue/
cd /Users/dan.peterson/Projects/go/src/github.com/dpiddy/rebuild-issue/foo
/usr/local/go/pkg/tool/darwin_amd64/compile -o $WORK/github.com/dpiddy/rebuild-issue/foo.a -trimpath $WORK -p github.com/dpiddy/rebuild-issue/foo -complete -buildid d3f5d07e80004854bdeba17217c73860f45300cb -D _/Users/dan.peterson/Projects/go/src/github.com/dpiddy/rebuild-issue/foo -I $WORK -pack ./bar.go
mkdir -p /Users/dan.peterson/Projects/go/pkg/darwin_amd64/github.com/dpiddy/rebuild-issue/
mv $WORK/github.com/dpiddy/rebuild-issue/foo.a /Users/dan.peterson/Projects/go/pkg/darwin_amd64/github.com/dpiddy/rebuild-issue/foo.a
mkdir -p $WORK/github.com/dpiddy/rebuild-issue/_obj/
mkdir -p $WORK/github.com/dpiddy/rebuild-issue/_obj/exe/
cd /Users/dan.peterson/Projects/go/src/github.com/dpiddy/rebuild-issue
/usr/local/go/pkg/tool/darwin_amd64/compile -o $WORK/github.com/dpiddy/rebuild-issue.a -trimpath $WORK -p main -complete -buildid 7f5babab889da2eb8522eb8afff090695f0b3427 -D _/Users/dan.peterson/Projects/go/src/github.com/dpiddy/rebuild-issue -I $WORK -I /Users/dan.peterson/Projects/go/pkg/darwin_amd64 -pack ./main.go
cd .
/usr/local/go/pkg/tool/darwin_amd64/link -o $WORK/github.com/dpiddy/rebuild-issue/_obj/exe/a.out -L $WORK -L /Users/dan.peterson/Projects/go/pkg/darwin_amd64 -extld=clang -buildmode=exe -buildid=7f5babab889da2eb8522eb8afff090695f0b3427 $WORK/github.com/dpiddy/rebuild-issue.a
mkdir -p /Users/dan.peterson/Projects/go/bin/
mv $WORK/github.com/dpiddy/rebuild-issue/_obj/exe/a.out /Users/dan.peterson/Projects/go/bin/rebuild-issue
rebuild-issue % rm -rf /usr/local/go                                                                                
rebuild-issue % curl -s https://storage.googleapis.com/golang/go1.6rc1.darwin-amd64.tar.gz | tar -C /usr/local -zxf -
rebuild-issue % rm $GOPATH/bin/rebuild-issue 
rebuild-issue % go install -x ./...                                                                               
WORK=/var/folders/5b/rh45nd3n5sz5phl9s2kx8vwhng20hp/T/go-build507762940
mkdir -p $WORK/github.com/dpiddy/rebuild-issue/_obj/
mkdir -p $WORK/github.com/dpiddy/rebuild-issue/_obj/exe/
cd /Users/dan.peterson/Projects/go/src/github.com/dpiddy/rebuild-issue
/usr/local/go/pkg/tool/darwin_amd64/compile -o $WORK/github.com/dpiddy/rebuild-issue.a -trimpath $WORK -p main -complete -buildid 7f5babab889da2eb8522eb8afff090695f0b3427 -D _/Users/dan.peterson/Projects/go/src/github.com/dpiddy/rebuild-issue -I $WORK -I /Users/dan.peterson/Projects/go/pkg/darwin_amd64 -pack ./main.go
# github.com/dpiddy/rebuild-issue
./main.go:3: import /Users/dan.peterson/Projects/go/pkg/darwin_amd64/github.com/dpiddy/rebuild-issue/foo.a: object is [darwin amd64 go1.6beta2 X:none] expected [darwin amd64 go1.6rc1 X:none]
rebuild-issue % grep -r . .
./foo/bar.go:package foo
./foo/bar.go:func Bar() {}
./main.go:package main
./main.go:import foo "github.com/dpiddy/rebuild-issue/foo"
./main.go:func main() {
./main.go:  foo.Bar()
./main.go:}

@dominikh noted the buildids for rebuild-issue.a were the same and also produced this:

dominikh-pc ~ $ grep -a "build id" /tmp/rc1/go/pkg/darwin_amd64/runtime.a 
build id "f5389452ffe6b0c06ad11e3fc2dddaa807ba04a5"
dominikh-pc ~ $ grep -a "build id" /tmp/b2/go/pkg/darwin_amd64/runtime.a 
build id "f5389452ffe6b0c06ad11e3fc2dddaa807ba04a5"

Perhaps this is a release process issue?

The text was updated successfully, but these errors were encountered:

ianlancetaylor · 2016-02-01T19:38:10Z

In a Go release, including go1.6beta2 and go1.6rc1, the standard library is not rebuilt even if it appears to be out of date. Your script will work as long as you are not working with releases, but if you are using releases you need to go install -a.

I'm sure enough that that is the problem here that I am going to close this, but please feel free to reopen if you disagree.

danp · 2016-02-01T19:50:38Z

Sorry, I don't follow. The main issue in my repro is getting this error for an object which is not part of the standard library:

./main.go:3: import /Users/dan.peterson/Projects/go/pkg/darwin_amd64/github.com/dpiddy/rebuild-issue/foo.a: object is [darwin amd64 go1.6beta2 X:none] expected [darwin amd64 go1.6rc1 X:none]

Is my understanding that objects in $GOPATH/pkg will be automatically rebuilt when changing Go versions incorrect? I thought #10702 was meant to address this.

ianlancetaylor · 2016-02-01T20:23:14Z

Sorry, I must have misunderstood.

ianlancetaylor · 2016-02-01T20:42:27Z

When I download https://storage.googleapis.com/golang/go1.6rc1.darwin-amd64.tar.gz I 'm puzzled by the fact that runtime/internal/sys/zversion.go says
const TheVersion = devel +0c4593d Thu Jan 28 18:11:15 2016 -0800
even though the top-level VERSION file says go1.6rc1. I don't understand how those can be different.

ianlancetaylor · 2016-02-01T20:42:58Z

This may have something to do with how the releases are built. CC @broady

danp · 2016-02-01T20:47:54Z

I did just try the same repro process but going from 1.5.2 to 1.5.3 and it worked as expected. So yes, perhaps something about building these beta/rc releases.

broady · 2016-02-01T21:30:35Z

That does look weird. I thought 1.6rc1 would be built as a "release" build, unlike the beta builds.

broady · 2016-02-01T21:44:53Z

Also, strange that the commit ID refers to one submitted in December last year:
0c4593d

I'd have expected it at least refer to 036b8fd, which is the commit that the go1.6rc1 tag points to.

danp · 2016-02-01T21:51:47Z

I get this:

% curl -s https://storage.googleapis.com/golang/go1.6rc1.darwin-amd64.tar.gz | tar -zxf -
% cat go/src/runtime/internal/sys/zversion.go
// auto generated by go tool dist

package sys

const DefaultGoroot = `/usr/local/go`
const TheVersion = `go1.6rc1`
const Goexperiment = ``
const StackGuardMultiplier = 1

danp · 2016-02-01T21:53:44Z

And for beta2:

% curl -s https://storage.googleapis.com/golang/go1.6beta2.darwin-amd64.tar.gz | tar -zxf - 
% cat go/src/runtime/internal/sys/zversion.go                                               
// auto generated by go tool dist

package sys

const DefaultGoroot = `/usr/local/go`
const TheVersion = `go1.6beta2`
const Goexperiment = ``
const StackGuardMultiplier = 1

broady · 2016-02-01T21:57:46Z

$ for f in *.gz; do echo -----$f-----; cat $f | gunzip | grep -a 'const.*TheVersion.*go1.6rc1'; done
-----go1.6rc1.darwin-amd64.tar.gz-----
    const @"".TheVersion = "go1.6rc1"
    const @"runtime/internal/sys".TheVersion = "go1.6rc1"
    const @"".TheVersion = "go1.6rc1"
const TheVersion = `go1.6rc1`
-----go1.6rc1.freebsd-386.tar.gz-----
    const @"".TheVersion = "go1.6rc1"
    const @"runtime/internal/sys".TheVersion = "go1.6rc1"
const TheVersion = `go1.6rc1`
-----go1.6rc1.freebsd-amd64.tar.gz-----
    const @"".TheVersion = "go1.6rc1"
    const @"runtime/internal/sys".TheVersion = "go1.6rc1"
    const @"".TheVersion = "go1.6rc1"
const TheVersion = `go1.6rc1`
-----go1.6rc1.linux-386.tar.gz-----
    const @"".TheVersion = "go1.6rc1"
    const @"runtime/internal/sys".TheVersion = "go1.6rc1"
const TheVersion = `go1.6rc1`
-----go1.6rc1.linux-amd64.tar.gz-----
    const @"".TheVersion = "go1.6rc1"
    const @"runtime/internal/sys".TheVersion = "go1.6rc1"
    const @"".TheVersion = "go1.6rc1"
const TheVersion = `go1.6rc1`
-----go1.6rc1.linux-armv6l.tar.gz-----
    const @"".TheVersion = "go1.6rc1"
    const @"runtime/internal/sys".TheVersion = "go1.6rc1"
const TheVersion = `go1.6rc1`
-----go1.6rc1.src.tar.gz-----

LGTM. @ianlancetaylor I'm not sure how you got to your result.

ianlancetaylor · 2016-02-01T22:11:26Z

Sorry, maybe I was mistaken. I'll check again.

ianlancetaylor · 2016-02-01T22:30:17Z

I'm sorry, my mistake entirely.

No idea what is going on here.

rsc · 2016-02-02T03:20:53Z

Hi @dpiddy. Thank you for putting together a reproduction case. I am trying to follow along, but go get github.com/dpiddy/rebuild-issue is failing for me: that repo seems not to exist? Maybe you forgot to push it to GitHub? Thanks again.

rsc · 2016-02-02T03:29:20Z

Never mind, @dpiddy. I made the obvious rebuild-issue importing foo based on your -x output and that reproduced the problem. Thanks again.

danp · 2016-02-04T14:01:01Z

Still having trouble with this, even with rc2. It might be a godep issue. Have a repro in the project that led to this issue being created, trying to create something self-contained.

danp · 2016-02-04T15:19:26Z

Ok, got it. Pushed to a repo this time with repro steps in the readme. Not godep specific but does seem to be a product of changing GOPATH. I can only trigger it if things are structured in such a way to get both GOPATH elements added. Maybe related to #14192?

davecheney · 2016-02-04T20:32:49Z

What happens if you reverse the order of the GOPATH entires, ie put
Godeps/_workspace after your normal GOPATH ?

On Fri, Feb 5, 2016 at 2:19 AM, Dan Peterson notifications@github.com
wrote:

Ok, got it. Pushed to a repo
https://github.com/dpiddy/rebuild-issue-godep this time with repro
steps in the readme. Not godep specific but does seem to be a product of
changing GOPATH. I can only trigger it if things are structured in such a
way to get both GOPATH elements added. Maybe related to #14192
#14192?

—
Reply to this email directly or view it on GitHub
#14176 (comment).

danp · 2016-02-04T21:05:09Z

It works, added output from that case to the bottom of the readme.

davecheney · 2016-02-04T21:13:13Z

That's what I suspected, the stale check is being tripped up because the
two packages are in different GOPATHs (effectively)

On Fri, 5 Feb 2016, 08:07 Dan Peterson notifications@github.com wrote:

It works, added output from that case to the bottom of the readme.

—
Reply to this email directly or view it on GitHub
#14176 (comment).

danp · 2016-02-05T02:26:06Z

@davecheney so should this be reopened? Or is it a dup of #14192?

davecheney · 2016-02-05T02:38:12Z

Not sure, it looks related, but the pathology is different.

On Fri, 5 Feb 2016, 13:26 Dan Peterson notifications@github.com wrote:

@davecheney https://github.com/davecheney so should this be reopened?
Or is it a dup of #14192 #14192?

—
Reply to this email directly or view it on GitHub
#14176 (comment).

rsc · 2016-02-05T12:19:28Z

Reopening this issue because the repro case is here. It may be a dup of 14192 or not. I will look before the release.

rsc · 2016-02-09T03:57:28Z

Rereading repro case I'm nearly certain this is a dup of #14192 but will leave open until I've run the repro case and confirmed the fix for #14192 fixes it.

gopherbot · 2016-02-09T06:00:10Z

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

danp · 2016-02-09T06:08:46Z

Verified the CL fixed my repro.

bradfitz assigned rsc Feb 1, 2016

bradfitz added this to the Go1.6Maybe milestone Feb 1, 2016

bradfitz changed the title ~~object mismatch error switching between 1.6beta2 and rc1~~ cmd/go: object mismatch error switching between 1.6beta2 and rc1 Feb 1, 2016

ianlancetaylor closed this as completed Feb 1, 2016

ianlancetaylor reopened this Feb 1, 2016

gopherbot closed this as completed in 0ed70ef Feb 3, 2016

rsc reopened this Feb 5, 2016

gopherbot closed this as completed in ee45177 Feb 9, 2016

golang locked and limited conversation to collaborators Feb 28, 2017

gopherbot added the FrozenDueToAge label Feb 28, 2017

rsc removed their assignment Jun 23, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cmd/go: object mismatch error switching between 1.6beta2 and rc1 #14176

cmd/go: object mismatch error switching between 1.6beta2 and rc1 #14176

danp commented Feb 1, 2016

ianlancetaylor commented Feb 1, 2016

danp commented Feb 1, 2016

ianlancetaylor commented Feb 1, 2016

ianlancetaylor commented Feb 1, 2016

ianlancetaylor commented Feb 1, 2016

danp commented Feb 1, 2016

broady commented Feb 1, 2016

broady commented Feb 1, 2016

danp commented Feb 1, 2016

danp commented Feb 1, 2016

broady commented Feb 1, 2016

ianlancetaylor commented Feb 1, 2016

ianlancetaylor commented Feb 1, 2016

rsc commented Feb 2, 2016

rsc commented Feb 2, 2016

danp commented Feb 4, 2016

danp commented Feb 4, 2016

davecheney commented Feb 4, 2016

danp commented Feb 4, 2016

davecheney commented Feb 4, 2016

danp commented Feb 5, 2016

davecheney commented Feb 5, 2016

rsc commented Feb 5, 2016

rsc commented Feb 9, 2016

gopherbot commented Feb 9, 2016

danp commented Feb 9, 2016

cmd/go: object mismatch error switching between 1.6beta2 and rc1 #14176

cmd/go: object mismatch error switching between 1.6beta2 and rc1 #14176

Comments

danp commented Feb 1, 2016

ianlancetaylor commented Feb 1, 2016

danp commented Feb 1, 2016

ianlancetaylor commented Feb 1, 2016

ianlancetaylor commented Feb 1, 2016

ianlancetaylor commented Feb 1, 2016

danp commented Feb 1, 2016

broady commented Feb 1, 2016

broady commented Feb 1, 2016

danp commented Feb 1, 2016

danp commented Feb 1, 2016

broady commented Feb 1, 2016

ianlancetaylor commented Feb 1, 2016

ianlancetaylor commented Feb 1, 2016

rsc commented Feb 2, 2016

rsc commented Feb 2, 2016

danp commented Feb 4, 2016

danp commented Feb 4, 2016

davecheney commented Feb 4, 2016

danp commented Feb 4, 2016

davecheney commented Feb 4, 2016

danp commented Feb 5, 2016

davecheney commented Feb 5, 2016

rsc commented Feb 5, 2016

rsc commented Feb 9, 2016

gopherbot commented Feb 9, 2016

danp commented Feb 9, 2016