1

Recently stumbled on this article about leveraging Go's shared library compiler in C and other languages: https://medium.com/learning-the-go-programming-language/calling-go-functions-from-other-languages-4c7d8bcc69bf

I'm wondering what the limitations of the compiler use is? For example once compiled will Go's net and socket libraries all work as they would as a standalone Go application?

ie. could I theoretically have a Go application as the communication layer (lets say HTTP) and a C application performing some lower level processing which is handed to Go for delivery?

Sorry for the awkward explanation of the use case, simply trying to understand how Go would react in a compiled environment in general. I know very little about shared libraries at this level, so just a curiosity.

ddibiase
  • 1,412
  • 1
  • 20
  • 44
  • 1
    If you are interested in such stuff: Why not ask on golang-nuts? I think this would be the better place and yield more answers and real life examples. – Volker Nov 22 '17 at 07:16

1 Answers1

1

In theory, there are no limitations - conceptually the .so is just a bunch of machine code that happens to bundle a very smart memory manager, and expose an API that matches the shared library format.

There are, in practice, a minimal set of quirks. For instance, the program linking in the go .so can currently not call dlclose on it: https://github.com/golang/go/issues/11100

You may find the open list of issues mentioning c-shared to be helpful: https://github.com/golang/go/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20c-shared

Jacob Davis-Hansson
  • 2,603
  • 20
  • 26
  • Interesting. When you run the shared lib does it operate in its own thread/process or more appropriately where does it operate vis-a-vis the C thread you're running? – ddibiase Nov 22 '17 at 02:05
  • @ddibiase: a go shared library starts up the normal runtime, it just happens to have a different entry point. – JimB Nov 22 '17 at 13:28