[go] Support Linux and macOS via CGO

[qmuntal]

The current auto-generated Go code is using syscall.LoadLibrary and syscall.(*Proc).Call to interop with C libraries. This methods are not implemented for linux nor macOS, and Go team has stated that they are not planning to do so, as the official FFI interface is cgo, not syscall. More info in go#38825.

cgo is a full-featured Go/C interop framework which can be used in any OS and can be used to link go to link go to shared and static libraries. It has some inherent drawbacks, such as requiring a classic gcc/g++ tool-chain and complicating cross-compilation builds, yet it is the way to go in this situations. More info about cgo: link.

Related: #91

[alexanderoster]

Hi qmuntal,

this is a fantastic implementation, thank you so much. Do you think we should keep a seperate syscall implementation for windows or would that be a wrong move?
Not having to have a gcc on a windows system for compilation is a pretty heavy advantage.
Is it possible to transparently use different code on different platforms?

Thank you!

Alex

[qmuntal]

Requiring gcc on windows for compiling C/C++ is the go way, despite this could eventually change if msvc support is landed to the go toolchain, see golang/go#20982. I really think it would be ward to have a robust and mantainable code generation with such an assymetric implementation to bypass what cgo.

It can be done, but the benefits are minimal taking into account that installing mingw on windows is easy if documented appropiately, only 20% of Go developers primarly develop in Windows and only 6% develop only in Windows. Source: Go Developer Survey 2019

[alexanderoster]

Hi @qmuntal,

thank you so much for your contribution! I have tried to go another round and use the cdynamic headers instead of the c headers. You can find my branch and commit here:
2b5f4c0

A first prototype seems to work well for me, and avoids all linking issues you would have with the old version.
It would be great to get your feedback on this proposal.

Thank you,

Alex

[qmuntal]

@alexanderoster I'm not that familiarized with the c dynamic bindings generated by act, could you elaborate on the advantages on using them instead of letting cgo figure them for you?

Despite I don't yet understand how it works, the name dynamic make me think that static linking won't be supported, which is something very much appreciated in the Go ecosystem as it is facilitates a lot deployments. Am I wrong?

[alexanderoster]

@qmuntal: Well, with external libraries, you usually have 3 options.

• Static Linking (e.g. linking a .a file): Links the object code directly into the executable
• Dynamic Linking (e.g. linking a .so file): Links an dynamic library together with the .SO files and things get loaded at program launch
• Dynamic Loading: A dynamic library is loaded at anytime during run-time via dlopen (Linux) or LoadLibrary (Windows).

In our opinion, dynamic linking is the worst of the 3 options, since there is little control over where the library is loaded from (DLL Path security flaws are famous on Windows), and there is no control over error handling - immediately leading to DLL hells all over the place. I personally do not know any way of using a DLL with static linking. So ACT is usually as standard used with dynamic loading from absolute pathes.

We usually always use use ACT heavily for plugin frameworks, and there the choosing a file location to load from is very essential.

Do you think the current cgo headers allow GO to statically link .so files under Linux? Of so, we definitely should have a GoStatic option for the headers, but I still think that dynamic loading should be the default. For example then you can compile the Go executable with source code only and without having the final library in the same directory.

Thank you,

Alex

[qmuntal]

Dynamic loading is not supported by cgo out-of-the-box and the cdynamic headers seems a step in the right direction! I think I can do another iteration on your branch to support the three linking options, being dynamic loading the default one and enabling static/dynamic linking via an opt-in build tag.

[alexanderoster]

There has been significant progress, and I would progress this issue with tickets
#133 #123 #124 #125 #127