[kodablah]

According to the release notes [1], "For the amd64 architecture only, the compiler has a new option, -dynlink, that assists dynamic linking by supporting references to Go symbols defined in external shared libraries."...so I assume if you want all of your Go signatures visible in your shared Go libraries, you can do it on x64. I have not tested this myself.

1 - https://tip.golang.org/doc/go1.5#compiler

[dvirsky]

the question though is how do you go about actually loading it? can it be done without patching the runtime, or without running some C based "bridge" that loads the shared object file? I'm talking about a plugin architecture, say, where I want to load an implementor of an interface from a .so file, etc.

[kodablah]

Based on a cursory overview of the design document, this appears to be done by not putting all of the Go signatures in the library (e.g. ELF headers somewhere) but instead based on a hash. From the design document [1]: "The shared library should include a hash of the export data for each package that it contains. It should also include a hash of the export data for each shared library that it imports. These hashes can be used to determine when packages must be recompiled. These hashes should be accessible to any build tool, not just the go tool." To me this is basically saying that so long as the hashes of the .so file match your binary, your dynamic load should be able to trust the uses of the same interface known at compile time.

I have not yet seen the "plugin" package in https://tip.golang.org/pkg/ as promised under the heading of "A new package" in the design doc.

1 - https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGh...

[dvirsky]

But I'm wondering - will this mysterious "plugin" package require changes in Go's core runtime, or can I implement whatever functionality it will expose right now. It looks to me like it can't be done without some C bridge/glue while not changing Go itself.

[ianlancetaylor]

The mysterious "plugin" package does not yet exist, and won't be in the 1.5 release. I would encourage you to try to implement it and send in the changes. The ideas in the execution modes doc are being steadily filled in by people who need them.

[dvirsky]

Do you have any pointers as to where do I start? I mean I can see how I can probably do it with a C bridge, but I don't know the runtime well enough to attempt to do it without it. Glad it's written in Go now :)

[dvirsky]

maybe it can be done with some unsafe magic parsing ELF files or something?