Hacker News Reader

Comment by tirus | Hacker News Reader

Has anyone spotted the documentation for the new shared library system yet? Plugin-based architecture is one of the biggest things I've wanted in Go and it seems to finally be happening.

View on HN

I played around with this on my own, and the shared library system will only work with Linux binaries for now. I wasn't able to get it working with OS X or Windows, with the very clear message from Go telling me the "platform target is not supported."

I think it is mostly a getting started point, and not generally useful unless your only target is Linux (which very likely may be the case unless you're working on desktop apps).

The closest thing to documentation is still the design document: https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGh...

I've been playing around with it, here's a neat example that does shared library partial bindings for http.Server in C and Python: https://github.com/shazow/gohttplib

Is it possible to dynamically load libraries that have been compiled with -buildmode=shared in runtime from within a running Go program? The design doc talked about it IIRC.

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

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.

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...

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.

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.

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 :)

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

Reply on news.ycombinator.com