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: initializers not run on plugin load #17821
Comments
It seems to work using |
I've ran attached test case and on my
|
I started with |
I just realized that your original code also works for me (linux/amd64). |
working on an exact reproducible setup. |
Put my code in https://github.com/captncraig/plugintest. go env:
go version: in directory
|
Also deleted all of $GOPATH/pkg and $GOPATH/bin. No change. |
Hi @captncraig: I can also reproduce this with steps you've provided. |
It's weird. If you build plugin with commands:
Output is as expected:
Also there is significant difference between Plugin.pluginpath: |
Yes, there is a bug in the linker that is easy enough to fix. I haven't done it yet because I'm trying to decide whether we should disallow unnamed package plugins altogether. Without a name, we have to assume that either all |
Is the package path not "baked in" to the plugin binary at compile time? I would generally foresee building all of my plugins in a similar way, so if one is unnamed, multiple different ones may be as well. It would be nice if file locations and working directories mattered as little as possible. |
This is what I think. A plugin built outside of When opening a plugin with no path, we should disambiguate only by the file name used to open the plugin. If the same .so is opened under multiple names, so be it. |
That makes sense to me. I'll have cmd/go generate a -pluginpath flag for cmd/link with a random suffix so that there are no symbol collisions, then modify the plugin package to detect these nameless plugins and use the file path instead for identification. |
CL https://golang.org/cl/32916 mentions this issue. |
CL 32355 switched from using the output file as a plugin prefix to the full package path. The linker dead code analysis was not updated. Updates #17821 Change-Id: I13fc45e0264b425d28524ec54c829e2c3e895b0b Reviewed-on: https://go-review.googlesource.com/32916 Reviewed-by: Ian Lance Taylor <iant@golang.org>
I think we need some kind of "plugin path" for plugins built outside I've tried using the symbol name |
CL https://golang.org/cl/33162 mentions this issue. |
Updates #17821 Change-Id: Iebd2e88b2d4f3d757ffad72456f4bfc0607d8110 Reviewed-on: https://go-review.googlesource.com/33162 Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
I think the major issues here are basically fixed. There's still some nicer handling we could do of nameless plugins as Ian suggested, but I believe it will only improve the quality of errors. That I think it can wait for a later Go release. |
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?Tip:
go version devel +2b445c7 Sat Nov 5 23:59:04 2016 +0000 darwin/amd64
What did you do?
Plugin package built with
go build -buildmode=plugin
:Host App:
What did you expect to see?
I expected to see the
INIT!
line from the plugin init printed as per the docs. Instead, that line seems to be missing. Full output:Am I misreading how plugin loading works, or is it not working as intended?
The text was updated successfully, but these errors were encountered: