You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to distribute some cgo bindings to a C++ library as a pre-compiled binary package in order to avoid asking users of this package to enable cgo and install gcc.
So I ended up on #28152 which says to use the Go plugins to do so. But now that I have my plugin wrapping the cgo bindings, I discover through my failing tests and in #28983 (comment) that "you have to build the plugin with the same dependencies as the binary".
I am unsure of what is exactly checked, but in this given use-case, the plugin cannot be built with the same packages as the binary that will load it. This binary is unknown in my case and I wanted to use the plugins as a way to load my package with cgo into any Go binary.
So this is very unexpected given the "plugin" name, and I am back to my starting point, for now giving up with plugins and rather document what it takes to use cgo because of my package.
Note that I also tried to find a way to simply use -buildmode archive and simply pass the compiled archive to go build or install without success.
The text was updated successfully, but these errors were encountered:
I think that everything you say in true. You can only use a plugin with the exact same Go release. Yes, this is a serious limitation on plugins, but there are no current plans to expand them. Sorry.
I'm going to close this issue because I don't really see any action we can take. Please comment if you disagree. You may also want to discuss this on a forum; see https://golang.org/wiki/Questions.
You can only use a plugin with the exact same Go release.
@iamoryanmoshe It's even stronger than this: the compiled dependencies needs to be the same, and this seems to be enforced by checking the import paths in the importcfg.
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
I would like to distribute some cgo bindings to a C++ library as a pre-compiled binary package in order to avoid asking users of this package to enable cgo and install gcc.
So I ended up on #28152 which says to use the Go plugins to do so. But now that I have my plugin wrapping the cgo bindings, I discover through my failing tests and in #28983 (comment) that "you have to build the plugin with the same dependencies as the binary".
I am unsure of what is exactly checked, but in this given use-case, the plugin cannot be built with the same packages as the binary that will load it. This binary is unknown in my case and I wanted to use the plugins as a way to load my package with cgo into any Go binary.
So this is very unexpected given the "plugin" name, and I am back to my starting point, for now giving up with plugins and rather document what it takes to use cgo because of my package.
Note that I also tried to find a way to simply use
-buildmode archive
and simply pass the compiled archive to go build or install without success.The text was updated successfully, but these errors were encountered: