go: plugin: panic: plugin was built with a different version of package

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

@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.

@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.”

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!

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?

I have basically tried everything and in the end I have this error: plugin was built with a different version of package internal/goarch". I am using exact same dependencies, go version, built environments, flags, etc…

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.

Apparently disabling optimizations and inlining -gcflags="all=-N -l" “resolves” the issue for me, but the output files are huge 😦

go build -buildmode=plugin -gcflags="all=-N -l" -o plugins/test.so plugins/test.go

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!

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

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

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

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