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
cmd/go: plugin versions do not match when built within vs. outside a module #31354
Comments
Bump. Any plans to fix this? Seems that algorithm which verifies package version integrity needs alignment. |
This is the same underlying problem as #29814. The workaround should be to build both the plugin and the main binary from outside of their respective repositories, or (as you note) to use a |
CC @jayconrod |
See also #31278, of which this may be a duplicate. |
There are several similar tickets; apologies if this is not the right place to comment. If the path is different but the version of the libraries are identical, we get version mismatch errors. A way of replicating this is to build the calling program in a container, and build the plugin outside of the container. The paths may look like this:
Building locally, and where:
echo $(TZ=UTC git show -s --format=%cd --date=format-local:%Y%m%d%H%M%S HEAD | cut -b -19 | tr -cd '[:digit:]')-$(git rev-parse HEAD | cut -b -12)
# Error:
2:31:33 main.go:485: plugin.Open("dummy"): plugin was built with a different version of package github.com/xxxserxxx/gotop/v3/devices
$ #######################################################
$ strings ./gotop | grep 'v3/devices$'
go.link.pkghashbytes.github.com/xxxserxxx/gotop/v3/devices
go.link.pkghash.github.com/xxxserxxx/gotop/v3/devices
%github.com/xxxserxxx/gotop/v3/devices
go.link.pkghashbytes.github.com/xxxserxxx/gotop/v3/devices
go.link.pkghash.github.com/xxxserxxx/gotop/v3/devices
$ #######################################################
$ strings dummy.so | grep 'v3/devices$'
go.link.pkghashbytes.github.com/xxxserxxx/gotop/v3/devices
go.link.pkghash.github.com/xxxserxxx/gotop/v3/devices
github.com/xxxserxxx/gotop-dummygithub.com/xxxserxxx/gotop-dummygithub.com/xxxserxxx/gotop/v3/devices
%github.com/xxxserxxx/gotop/v3/devices
go.link.pkghashbytes.github.com/xxxserxxx/gotop/v3/devices
go.link.pkghash.github.com/xxxserxxx/gotop/v3/devices I've played with copying the If I add the following to the plugin's
then it works. EditRewrote some of the text to be more readable, I hope. Edit 2I made an error: I need to remove the |
Same thing happens for me for a go.mod-based project regarding the |
Another data point which I can't even begin to interpret: $ git clone https://github.com/xxxserxxx/gotop
$ git clone https://github.com/xxxserxxx/gotop-dummy
$ cd gotop && git checkout v3.5.0
$ go build -o gotop ./cmd/gotop
$ cd ../gotop-dummy && grep gotop go.mod
require github.com/xxxserxxx/gotop/v3 v3.5.0
$ go mod download
$ go mod vendor
$ go build --buildmode=plugin -o ../gotop/dummy.so .
$ cd ../gotop
$ ./gotop -X dummy # this hangs for some reason; ^C to break
$ cat ~/.local/state/gotop/errors.log
13:03:16 main.go:485: plugin.Open("dummy"): plugin was built with a different version of package github.com/shirou/gopsutil/internal/common
$ go mod graph | grep gopsutil
github.com/xxxserxxx/gotop/v3 github.com/shirou/gopsutil@v2.18.11+incompatible
➜ gotop git:(be42ba5) ✗ git log -1
commit be42ba538cefc892d1dc3d18c783483f4875baff (HEAD, tag: v3.5.0)
$ cd ../gotop-dummy
$ go mod graph | grep gopsutil
github.com/xxxserxxx/gotop/v3@v3.5.0 github.com/shirou/gopsutil@v2.18.11+incompatible These are the identical dependencies. Why is the system claiming that they are not? |
This comment was marked as off-topic.
This comment was marked as off-topic.
do you mean to say, that the |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as spam.
This comment was marked as spam.
The current plugin mechanism does not allow you to avoid mixed package hashes. For example, this error occurs when a main application that references package A loads plugins that references A. I often use gophernotes to try to write notebook with Go. gophernotes reference mattn/go-runewidth. So gophernotes can not import mattn/go-runewidth on the notebooks. I have to disable Go code to avoid this. diff --git a/src/runtime/plugin.go b/src/runtime/plugin.go
index cd7fc5f848..ace1b13ed9 100644
--- a/src/runtime/plugin.go
+++ b/src/runtime/plugin.go
@@ -48,12 +48,14 @@ func plugin_lastmoduleinit() (path string, syms map[string]interface{}, errstr s
throw("plugin: new module data overlaps with previous moduledata")
}
}
- for _, pkghash := range md.pkghashes {
- if pkghash.linktimehash != *pkghash.runtimehash {
- md.bad = true
- return "", nil, "plugin was built with a different version of package " + pkghash.modulename
+ /*
+ for _, pkghash := range md.pkghashes {
+ if pkghash.linktimehash != *pkghash.runtimehash {
+ md.bad = true
+ return "", nil, "plugin was built with a different version of package " + pkghash.modulename
+ }
}
- }
+ */
// Initialize the freshly loaded module.
modulesinit() |
@rsc Hi Russ, |
A fix for this issue would require changes to the compiler (to prevent cross-package inlining when building plugins), and probably the linker (to interpret and record a signature for the package ABI). That's possible, but it would be a lot of work to support a fairly esoteric build mode. @jeremyfaller could perhaps speak to whether the compiler and linker folks are planning to implement that support, but to my knowledge it's not on the roadmap at this time. |
@bcmills's knowledge is correct. We've kicked around improving this for some time, but those things are just thoughts. It's a complicated problem, and it's almost certainly not on the roadmap for 2022. |
just ran into this problem and cannot get it working even with a replace directive in the plugin's go mod file. |
This comment was marked as spam.
This comment was marked as spam.
This comment has been hidden.
This comment has been hidden.
This is mostly a chicken and egg problem where many projects are not utilizing plugins due to their complicated build setup and other limitation (version incompatibility, requiring a main packet, linux only) while the plugin system does not get improved because very few projects are using it. However the demand certainly exists. |
If look around, there are plenty of incomplete and partially-working attempt to deal with plugins, just because current system is way too restricting. At the end, a lot of efforts lost for nothing and 1) adoption of current plugins system is subpar, and 2) people waste time re-introducing wheel.
giving user options to make unsafe (and unrecommended) choice and deal with potential fallout on it's own, adoptions of plugin system will jump tremendously, which on it's own will lead to improvement of it. Solving chicken and egg issue from above. Of course, it is not even close to be real solution. But rather temporary patch. But it give chance to actually use it. In a current form it is not plugin system, it is merely lazy loading. The only realistic option to ensure than plugin will load, is to build is a part of source tree of the main code as part of the same compilation process. or just rename to "lazy_load" to stop confusing people :) |
I try to import this and finally give up, maybe try the wasm. |
So its 2023 and i did run in the same issue as the rest here. I have a repostiory for my application and a respostiory for the plugin code. The idea was to write an application that can be fed by custom developed plugins for execution. Tho even considering the workarround with the alias it would be quite uncomfortable for people to use Plugins and this way of extending the apllication than. I think this definatly should be considered to be solved since the net is allover filled with people hitting this issue and this thread now is ongoing for about 4 years with people asking for a solution. |
What did you do?
I have simple application that loads Go plugins and allows them to communicate with app via exported interface.
Simplified version can be found here.
Shared interface is stored under
ext
directory, real implementation is located underplugin
directory.Application passes pointer to real implementation to dynamically loaded plugin which expects interface.
Example plugin code can be found here.
Unfortunately combination of Go Modules and Go Plugins doesn't work unless go.mod of plugins module has
replace
entry with local relative path for shared interface path.When I use remote location in plugins module, application crashes because of wrong version of packages.
Build app:
Then build plugin
When I change plugins go mod to use local path instead of remote one everything works.
What did you expect to see?
Go Modules and plugins working fine when remote path is used.
What did you see instead?
Error about different package versions.
Does this issue reproduce with the latest release (go1.12.3)?
Yes.
System details
The text was updated successfully, but these errors were encountered: