Hi, I’m quite new to Corteza, it’s open architecture fit’s my personal attitude.
Now I’m experimenting with plugins and reached a point where I have no idea why the plugin loader is complaining. This is what I get:
plugin.Open("../randomplugin/randomplugin"): plugin was built with a different version of package internal/goarch
I’m using Corteza version 2022.3.3-rc.1.
I checked twice that my go version number in my go.mod file is the same. I tried 1.18 and 1.17 in Corteza server’s go.mod and in my plugin go.mod. I’m using go 1.18.2.
My first assumption was that “make watch” calls gin and as a proxy has another binary version of go libs, but when running corteza server directly after “make build”, I get the same error.
I even wrote a dummy Go plugin loader app to test if there is some general problem on my go setup and that works like a charm, I can load the so file and call the “CortezaPlugin” function.
This is how I link my *.so file in my .env file:
PLUGINS_PATHS=../randomplugin/*.so
I’m developing in WSL2, but randomplugin and corteza-server are both developed in the same Ubuntu instance.
My GOOS is “linux” and my GOARCH is “amd64” - checked right before the compilation of both binaries.
This is how I compile my plugin:
go build -buildmode=plugin -o randomplugin.so main.go
Do you have any idea about what I’m doing wrong?
have you found out anything new regarding this issue?
We’ve been using the plugin system on the 2021.9.x version with golang version 1.16 without any problems, but from 1.17, the build process for us does not work anymore.
How we have been using the plugins is create a subdir in corteza repo (symlink does not work well, not sure if WSL supports them), add a Makefile to that subdir and remove any vendor/ that gets created there.
Then from the corteza repo dir call the build for that plugins
$ make -C plugins-test/ clean build
The build is exactly the same as yours, using buildmode.
If you have some more info on that do share here, sorry for the delay answering this, cheers
I think I was able to get a bit into the main problems here.
The Golang repo has multiple tickets regarding that and it all comes down to two main problems:
using “-trimpath” as a compiler parameter for both the server and the plugin
not compiling two different versions of a package in server and plugin
-trimpath didn’t really help me any further, the next error I got was
plugin.Open("../plugin_vorgangsnummer/plugin_vorgangsnummer"): plugin was built with a different version of package github.com/cortezaproject/corteza-server/pkg/http
The second point is the more important one and I think I have some idea what happens. Whenever you compile a plugin, you compile most of the corteza-server together with it. The packages you reference in the plugin - in my case
reference themself A LOT of corteza servers code, including implementation parts.
I tried to separate it a bit by copying all the stuff to an own project directory (the hacky way, just to find out what happens), but now I give up…after finding out that everything is dependent on everything in corteza-server and fixing all the errors after removing the http package, I’m now at the next level:
plugin.Open("../plugin_vorgangsnummer/plugin_vorgangsnummer"): plugin was built with a different version of package gopkg.in/yaml.v3
So next up would be to remove all dependencies for that…but without knowing what comes next.
The github tickets for Golang have one consent from what I read: The plugin system is broken.
I see only a few options now:
hoping that Golang fixes it’s plugin system
use your mentioned Golang plugin system over gRPC (never used it, but performance may be a challenge)
refactor corteza-server to separate all plugin dependencies from the server part (which is quite challenging as there are a lot of cross references) and hope for the best (no guarantee that this will work)
thanks for the extensive research, I was hoping you’d get further than I did
-trimpath didn’t really help me any further, the next error I got was
I was tinkering with this one as well but did not help either
hoping that Golang fixes it’s plugin system
I’m not holding any breath here
refactor corteza-server to separate all plugin dependencies from the server part (which is quite challenging as there are a lot of cross references) and hope for the best (no guarantee that this will work)
too much work if at all possible
use your mentioned Golang plugin system over gRPC (never used it, but performance may be a challenge)
if you decide on working on this one we would really appreciate any outcome, be it in more info or even better, a PR
Thanks for all the input on this one, much appreciated
