CC @crawshaw

There are too many layers here for me to dig through your example, sorry.

Is it possible that you have two different copies of package errors? Maybe the plugin is built with an older or newer copy?

So here is a simpler reproduction of the problem from Go 1.9 (we were not experiencing problems in 1.8.3):

• Download and extract Go 1.9 (using Linux x86_64 here)
• Create main.go and plugin.go following the example from the documentation for the plugin package, but add a needless import of the plugin package to the plugin:

// main.go
package main

import "plugin"

func main() {
  p, err := plugin.Open("plugin.so")
  if err != nil {
    panic(err)
  }
  v, err := p.Lookup("V")
  if err != nil {
    panic(err)
  }
  f, err := p.Lookup("F")
  if err != nil {
    panic(err)
  }
  *v.(*int) = 7
  f.(func())() // prints "Hello, number 7"
}

// plugin.go
package main

import "fmt"

// XXX this is weird
import _ "plugin"

var V int

func F() { fmt.Printf("Hello, number %d\n", V) }

• Build these and run main:

$go build -buildmode=plugin plugin.go 
$go build main.go
$./main
panic: plugin.Open: plugin was built with a different version of package plugin

goroutine 1 [running]:
main.main()
	/home/rmccoll/tmp/main.go:8 +0x3bb

• Now go into the go src for runtime and plugin and force them to rebuild:

cd /usr/local/go/src/runtime && go install -a
cd /usr/local/go/src/plugin && go install -a

• Rebuild your plugin and main and run again:

$go build -buildmode=plugin plugin.go 
$go build main.go
$./main
Hello, number 7

• Scratch head for a while...

Thanks for the reproduction, that gives me an idea what's happening.

Could you try patching your Go installation with https://golang.org/cl/61071 and rebuilding with make.bash?

That CL doesn't look relevant, but I believe because one copy of the plugin package is built with -gcflags=-shared and one is built without, they have different version hashes, which is why you're seeing that error.

(Unrelated to this issue: if the bugs I've been hunting down with CL 61071 turn out "just" to be version mismatches, maybe there's some other solution to that problem.)

My guess about what's happening: the C/C++ compiler used by cgo to build the version of Go 1.9 you downloaded is different from your local C/C++ compiler.

When you build the main binary, it uses the shipped .a files.

When you build the plugin, it gets built with -shared, which requires building different .a files than the ones that came in the release, so your C/C++ compiler is invoked. The C/C++ object code in the plugin package is slightly different, so a different version hash is computed.

The only general solution to this is relaxing the versioning scheme we are using. (For example, if we hashed exported APIs this wouldn't be a problem.)

Hmm, that explanation isn't wholly satisfying, because the part of the PKGDEF being used to generate the version doesn't seem to obviously include any mention of the cgo parts of the package.

@robmccoll I have simply been overanalyzing this. There is something off about the .a files that come with the Go 1.9 binary distribution.

If you download it, then use ar x to extract the __.PKGDEF from $GOROOT/pkg/linux_amd64/plugin.a (the contents of __.PKGDEF is used to build the package version for plugins) you get one piece of binary export data. Then run go install -a std and do it again, and you get another piece of binary export data.

The variants -installsuffix=shared -gcflags=-shared and -installsuffix=dynlink -gcflags=-dynlink produce the same binary export data as the default install. The odd file out comes with the binary distribution.

I'll work out how to unpack it and see if I can spot the difference. For now, the quick fix is go install -a std.

@griesemer, @alandonovan do you have any tools for pretty printing the binary export format? I've started hacking up something using go/types, but I think it may be hiding the the minor differences between these files.

@mdempsky see previous comment.

Staring at the bytes revealed that the binary export data has an absolute path in it from where the 1.9 tarball was built:

/tmp/workdir/go..._plugin_dlopen.go

when I build the .a files again with go install -a std, it gets replaced with the absolute path to my workstation's GOROOT.

Presumably this has something to do with cgo. Still reading code.

So it looks like absolute paths in the binary export position information is deliberate (there are calls to AbsFilename in cmd/compile's bexport.go).

Is this intended, @griesemer, @mdempsky? If so, do we not care about reproducible builds for intermediate .a files?

Regardless, we need a new strategy for -buildmode=shared and -buildmode=plugin, which use a hash of the export data for versioning. With absolute paths, builds cannot reproduce, and plugin versions are no use.

One option would be for the compiler could generate the hash for the linker, from the export data minus the position information.

Another option would be for the linker could learn to parse the export data and do it. This is more work, but may be a useful first step towards generating more useful versioning information for the non-default build modes.

Huh - sorry I missed the updates so far. For now, we've just added rebuilding the standard library as part of the scripting for setting up our build environment.

I'm curious - how were the package hash contents chosen? Were the paths really intended to be paths or is that just the overlap between the filesystem and import paths? What would be the impact of not including it?

Change https://golang.org/cl/63693 mentions this issue: cmd/compile: replace GOROOT in //line directives

Is this slated for 1.9.2?

CL 63693 is slated for 1.9.2 because of #21825.

Change https://golang.org/cl/70975 mentions this issue: [release-branch.go1.9] cmd/compile: replace GOROOT in //line directives