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

plugin: panic: plugin was built with a different version of package #27751

Open
juhwany opened this issue Sep 19, 2018 · 22 comments
Open

plugin: panic: plugin was built with a different version of package #27751

juhwany opened this issue Sep 19, 2018 · 22 comments
Milestone

Comments

@juhwany
Copy link

@juhwany juhwany commented Sep 19, 2018

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go version go1.11 darwin/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN="/Users/juhwany/go_workspace/bin"
GOCACHE="/Users/juhwany/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/juhwany/go_workspace"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/juhwany/gos/go_server/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/mk/2tyywdsn0jq6l0vl8094tss80000gp/T/go-build380269681=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

  1. Clone the blow repo in each directory. (not under GOPATH)
    server (main program) : https://github.com/juhwany/go_server
    plugin : https://github.com/juhwany/go_plugin

  2. On same machine, build server & plugin in each directory
    Build server : go build -o main
    Build plugin : go build -buildmode=plugin -o plugin.so

  3. Copy plugin.so to server directory and run
    ./main

  4. See error message when main program try to open plugin.

panic: plugin.Open("plugin"): plugin was built with a different version of package github.com/juhwany/go_server/v2/apis

What did you expect to see?

Main program should load plugin.so successfully.
I could not understand why it fails even though the referenced package version is same between main program and plugin.
Am I using plugin in wrong way?

What did you see instead?

plugin was built with a different version of package error message

@juhwany juhwany changed the title plugin was built with a different version of package plugin was built with a different version of package error Sep 19, 2018
@randall77
Copy link
Contributor

@randall77 randall77 commented Sep 19, 2018

Related (dup?) #26759 .

@juhwany
Copy link
Author

@juhwany juhwany commented Sep 20, 2018

@randall77

No. I think building environment is slightly different from #26759.
I didn't build main program and plugin under GOPATH and the above sample project uses Go module for specifying dependency package. Go version is also different.

@BryceDFisher
Copy link

@BryceDFisher BryceDFisher commented Sep 21, 2018

I do think they are all related though, including #27062. I think it all boils down to changing (absolute) paths at build time between the plugin build and the app build.

@bcmills
Copy link
Member

@bcmills bcmills commented Sep 22, 2018

@bcmills bcmills changed the title plugin was built with a different version of package error plugin: panic: plugin was built with a different version of package Sep 22, 2018
@bcmills bcmills added this to the Go1.12 milestone Sep 22, 2018
@tamasfe
Copy link

@tamasfe tamasfe commented Oct 8, 2018

I'm not sure if anyone's already mentioned it, but putting the common(apis) package to a separate module outside the server one will work. It's definitely cumbersome, but can be used as a workaround until this issue is fixed.

@oszika
Copy link

@oszika oszika commented Nov 13, 2018

The command "go list -m -json all" shows version of go_server on go_plugin, but it's not defined on go_server itself. I have a similar problem using multiples modules on the same repository using "replace" directive. I don't know how to have the same version of the module inside and outside the repository.

@oszika
Copy link

@oszika oszika commented Dec 1, 2018

In #28983, @bcmills suggests to build plugins from within the main module.

// server/go.mod
module github.com/juhwany/go_server/v2
require github.com/juhwany/plugin v0.0.0
replace github.com/juhwany/plugin => ../go_plugin

$ go build -buildmode=plugin github.com/juhwany/plugin
$ go run main.go 
DoSomething called!
@jbrukh
Copy link

@jbrukh jbrukh commented Jul 10, 2019

Just throwing in my two cents here. Both the @tamasf97 and @oszika are workarounds.

However, @tamasf97's workaround only works if you can factor the shared code out without creating a circular dependency (not always possible).

@oszika's workaround using the "replace" directive is pretty inconvenient for clients of the shared code, as you need that local repo.

@itsmontoya
Copy link

@itsmontoya itsmontoya commented Feb 28, 2020

We are unable to run our plugin-based service with gomod due to this issue.

@dhalman
Copy link

@dhalman dhalman commented Feb 28, 2020

We are experiencing this issue after implementing go.mod in both the server and plugin

@bcmills
Copy link
Member

@bcmills bcmills commented Feb 28, 2020

@itsmontoya, @dhalman: what specific commands did you run to build the plugin?

(Did you follow the approach in #27751 (comment)? Did you build with -trimpath? Both of those may be necessary.)

@itsmontoya
Copy link

@itsmontoya itsmontoya commented Feb 28, 2020

@bcmills we will try -trimpath and the other approach and get back to you ASAP! 👍

@dhalman
Copy link

@dhalman dhalman commented Mar 1, 2020

added -trimpath and the error moved from our microservice dependency lib to now internal/cpu:

plugin.Open("plugins/thePlugin"): plugin was built with a different version of package internal/cpu
@novabyte
Copy link

@novabyte novabyte commented Mar 1, 2020

@dhaimeen We've used the Go plugin API for quite a while now (over a year) and the error "different version of package internal/cpu" occurs when you've not used the -trimpath flag on both the shared object you build (plugin) and the main binary. Both bundle a copy of the Go runtime (although there's an open issue on the tracker about not packaging a copy of the Go runtime with plugin code). Hope this helps.

@dhalman
Copy link

@dhalman dhalman commented Mar 2, 2020

The main bin solved it for us in a manual build process. Thank you!!

We are now running into an issue where it appears -trimpath isnt working as expected when running from a command in the .Exec(...) env

The .so files produced by the exec command differ from the files produced by go build in the cli

@dhalman
Copy link

@dhalman dhalman commented Mar 3, 2020

Ok, I think we have determined the difference:

Successful:

cd <path-to-plugin>
go build -trimpath -buildmode=plugin -o <filename> 

Unsuccessful:

go build -trimpath -buildmode=plugin -o <filename> <path-to-plugin>

Are there any ways to determine why the latter fails to produce the same output as the former?

Thanks!

@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Mar 3, 2020

@dhalman I think you can try using go build's -x flag, e.g.

go build -x -trimpath -buildmode=plugin -o <filename>

to print out how the go command invokes the compiler and the linker, and how it differs.
Maybe you want to do a go clean -cache first.

@bcmills
Copy link
Member

@bcmills bcmills commented Mar 4, 2020

@dhalman, is the plugin in the same module as the main binary? If not, the module metadata could be what's throwing it off.

Do you have any cgo dependencies? That could also do it (#36072).

@bcmills bcmills modified the milestones: Unplanned, Backlog Mar 4, 2020
adrianlzt added a commit to datadope-io/skydive-plugins that referenced this issue May 19, 2020
easyjson does not work with main packages. Workaround changing the
package name as suggested in mailru/easyjson#236

Some code has been moved from skydive to graffity: common.Getter

Clean and update gomod:
k8s deps should be added with replace, kubernetes/kubernetes#79384
Same problem with networkservicemesh
viper is not being used
add skydive as dep, not local replace

Once compiled it fails to run with skydive because problems with the Go
plugin framework.
The error is: plugin was built with a different version of package golang.org/x/sys/unix

golang/go#20481
golang/go#27751
adrianlzt added a commit to datadope-io/skydive-plugins that referenced this issue May 19, 2020
easyjson does not work with main packages. Workaround changing the
package name as suggested in mailru/easyjson#236

Some code has been moved from skydive to graffity: common.Getter

Clean and update gomod:
k8s deps should be added with replace, kubernetes/kubernetes#79384
Same problem with networkservicemesh
viper is not being used
add skydive as dep, not local replace

Once compiled it fails to run with skydive because problems with the Go
plugin framework.
The error is: plugin was built with a different version of package golang.org/x/sys/unix

golang/go#20481
golang/go#27751

Tested adding to the skydive.yml config file:
plugin:
  plugins_dir: /home/adrian/go/src/github.com/skydive-project/skydive-plugins/memory
  topology:
    probes: memory
@mytototo
Copy link

@mytototo mytototo commented May 26, 2020

I have a collection of Go plugins I need to package and distribute. When building and running on my machine everything works as expected. However plugins don't work on other machines.

Here is the command I execute:

$ GO111MODULE=on go build -trimpath -buildmode=plugin -o ./my-plugin.so ./my-plugin-directory

I tried running the parent application calling the plugins both with and without -trimpath. Nothing works.

How can I fix this behavior?

@paralin
Copy link

@paralin paralin commented Jul 4, 2020

@bcmills I got caught up on this one with modules - the problem can occur when you import a package from the same module in the "loader," and you import the same package but from a different module in the "plugin."

@dhalman
Copy link

@dhalman dhalman commented Jul 5, 2020

We have developed an open source solution for syncing go.mod repositories across large projects with internal dependencies. We find it especially useful for managing large collections of plugins along with their private imports.

Happy to share it if requested, but would not want to advertise in this forum

@mytototo
Copy link

@mytototo mytototo commented Jul 6, 2020

@paralin Do you have a working and a non-working example so I can try to reproduce your solution? I am not sure to fully understand.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.