Why is buildmode=c-shared distinct from buildmode=plugin?

[kho...@gmail.com]

What is it about go internals that makes object files that C can link to as a shared library different from object files that can be used as plugins? For C to load shared objects from go as plugins, why isn't it sufficient to provide C initialization and deinitialization functions for the go runtime? This isn't a criticism, I'm just curious to know. Thanks.

[minux]

On Sun, Jan 15, 2017 at 6:41 AM, <kho...@gmail.com> wrote:

What is it about go internals that makes object files that C can link to as a shared library different from object files that can be used as plugins? For C to load shared objects from go as plugins, why isn't it sufficient to provide C initialization and deinitialization functions for the go runtime? This isn't a criticism, I'm just curious to know. Thanks.

The difference is mainly on the program that loads the shared library.

For c-shared, we can't assume anything about the host, so the c-shared dynamic library must be self-contained, but for plugin, we know the host program will be a Go program built with the same runtime version, so the toolchain can omit at least the runtime package from the dynamic library, and possibly more if it's certain that some packages are linked into the host program. (This optimization hasn't be implemented yet, but we need the distinction to enable this kind of optimization in the future.)