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
Comments
Related (dup?) #26759 . |
No. I think building environment is slightly different from #26759. |
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. |
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. |
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. |
In #28983, @bcmills suggests to build plugins from within the main module.
|
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. |
We are unable to run our plugin-based service with gomod due to this issue. |
We are experiencing this issue after implementing go.mod in both the server and plugin |
@itsmontoya, @dhalman: what specific commands did you run to build the plugin? (Did you follow the approach in #27751 (comment)? Did you build with |
@bcmills we will try |
added -trimpath and the error moved from our microservice dependency lib to now internal/cpu:
|
@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 |
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
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
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 How can I fix this behavior? |
@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." |
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 |
@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. |
…iling a monolith instead :-(
* updated mocks * ran into issue becuase we're using go modules so when tests are run they don't match the version of the plugin golang/go#27751 (comment)
* Made so that environment variables are expanded on the api config * Skipped tests that load the so. There are issues with compiling and loading the plugins in the test because of go modules. golang/go#27751 * Got other tests to pass (irrespective of which os you're on) * Added a test service to the docker to make the test environment consistent
Any process? |
I encountered the same issue while trying out this repo: https://github.com/vladimirvivien/gosh To reproduce it, this is the process: go version # go version go1.16 darwin/amd64
dlv version # Version: 1.6.0
git clone https://github.com/vladimirvivien/gosh
cd gosh
go mod init github.com/vladimirvivien/gosh # to fix the running issue This is all good: go build -buildmode=plugin -o plugins/splash_command.so plugins/00_splash.go
go build -buildmode=plugin -o plugins/sys_command.so plugins/syscmd.go
go run gosh.go # all good But when try debugging by setting the breakpoint at /gosh.go, line 59, I always get an error:
If I try this instead by adding the go build -trimpath -buildmode=plugin -o plugins/splash_command.so plugins/00_splash.go
go build -trimpath -buildmode=plugin -o plugins/sys_command.so plugins/syscmd.go
go run gosh.go I would get this error:
Why? |
Hey @dhalman, could you post the link to the open source syncing solution of yours. I find developing any a bit non-trivial plugin for any a bit non-trivial app a total nightmare. Maybe your solution might help me out. :) Cheers |
@kriptor i havent tried it in a while, but im here to help support if you do end up using it |
Hello, UP on this subjecT? |
I posted some comments here about this issue previously, right now you can view the workarounds I've built as well as a work in progress hot reloading system (which is hampered by this bug) here: https://github.com/aperturerobotics/controllerbus/tree/master/example/plugin-demo |
Thank you @paralin , but my problem is ... very ennoyinh. Package A include C version 1.1 ( go mod used ). Package B ( the plugin ) include C version 1.1 go mod used. Result, Plugin B was buillt with a different version of C. My "workaround" was to remove the go.mod used in the B package to make it works. Very dirty solution in my opinion. |
has an error loading at runtime ref: golang/go#27751 Signed-off-by: Avelino <avelinorun@gmail.com>
has an error loading at runtime ref: golang/go#27751 Signed-off-by: Avelino <avelinorun@gmail.com>
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?
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
On same machine, build server & plugin in each directory
Build server :
go build -o main
Build plugin :
go build -buildmode=plugin -o plugin.so
Copy plugin.so to server directory and run
./main
See error message when main program try to open plugin.
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 messageThe text was updated successfully, but these errors were encountered: