Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
plugin: using stdlib package plugin from c-archive package doesn't work as expected #18123
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
This is hard. We have not figured out how to implement a program that has multiple partial copies of the Go runtime. The immediate problem here is that the c-archive does not export the symbols that the plugin is looking for, so we have multiple copies of those symbols in the program space. But addressing that problem piecemeal is not going to work without an understanding of where we are headed, and I don't know the answer to that.
I don't see this happening for 1.8 unless @crawshaw can figure out a way.
I have no formal training/experience in that field, so my suggestions might be garbage. Please tell me if it is so, and why.
Couldn't you just declare all symbols that make up the runtime as weak, when -buildmode=plugin is used and advise users to link the c program with --export-dynamic/--dynamic-list if they want to use plugin from a c-archive? So if the plugin is loaded, the symbols from the c-archive overrule those in the plugin? Voila -> one runtime ? At least for elf platforms?
You could even make the go tool emit a list of symbols to be used with --dynamic-list like go list_runtime_symbols > file_for_dynamic_list.
I assumed there was a fixed list of symbols the writer of the program must list for
If the writer of the program doesn't anticipate the use of stdlib package plugin from within the c-archives he uses to link his program with, I would argue it is a security feature, if plugins stop to work, if he didn't use
On the other hand, if you could just do
why would that be worse then using pkg-config which you already do all the time?
Is there any way out of this bug? I don't think I quite understand the failure mode here (as a user)
I have a .so I built as ac-shared that tries to do a plugin.Open to an ELF that was built using buildmode=plugin. This seems to describe this issue, but I'm not quite sure on the best way to work around this.
I tried adding -dynamic-list and -dynamic-export to the LDFLAGS, but I was having trouble setting them correctly since I don't quite understand the magic behind plugin. I guess in the meantime I can just use c-shared and dlopen it, but I kinda hate having to rewrite hunks of stdlib in my app
(using go1.8.3 on a linux/amd64)
I believe I'm hitting a similar issue, but only on Linux. It works on macOS, surprisingly. I've created a repo to help reproduce the issue: https://github.com/JohnStarich/go-plugin-issues
The repo contains tests for normal Go executables loading plugins and also the indirect approach with a compiled C program loading a
Perhaps this working on macOS could be a clue to a possible solution. Is there anything I can do or provide that may help?
macOS environment info
Linux environment info
Edit: If this is not the same issue, let me know and I'll open a new one instead