runtime/cgo: How to integrate go (via cgo) with MSVC2013 project?

[haxwagon]

High level
Our team has grand aspirations of using Go as the common language between several projects (ios, android, windows, mac). Gomobile has filled the first two quite nicely and -buildmode=c-archive looks like what we'd want for windows/mac. Additionally, our library embeds sqlite3 and, thus, needs cgo.

Goal
The windows projects have a dll-based loader, that patches and loads dlls independently. We want to make our go-library's functionality available in these dlls.

Problem
We were able to build the static library on windows using mingw/msys, but it doesn't use the same cl.exe compiler that VS2013 (yes, it's old) uses to build the dlls. Are there any supported ways to build a static library using CC=VS2013? The exported cgo methods would then be adapted to dll methods.

Workaround
The workaround we use (which is certainly not ideal, and, also, not sellable to the windows team) is to build a small REST server with our go code and tie in the launching/closing of this process via the windows dll. Clearly we could use some other IPC/RPC to talk to this server, but we don't want to have to do that.

Question
Is there a cleaner build/strategy that would allow us to use go(and c via cgo) code in these windows dlls?

Thanks!
Matt

[bradfitz]

I'm tempted to close this with https://golang.org/wiki/Questions but I'll let @crawshaw decide what the best forum for stuff like this is. But generally we don't use our bug tracker for questions or general discussion.

[haxwagon]

I'm not sure if this is a x/gomobile question. The gomobile part works fine, this is more of a cgo quetsion.

[bradfitz]

Sure. To @alexbrainman then.

[minux]

Support building Go code into dll (which can be called by vs2003 compiled code) is fine, but I highly doubt that we are going to support using CC=cl.exe to build cgo code.

[haxwagon]

hey, I don't want to have to use that compiler :) But linking in the static artifact doesn't work. @minux have you ever tried this with some trivial example?

[alexbrainman]

I am not really an expert here, but ...

Correct me if I am wrong. You want to build your Go code as DLL and use it with one of your programs.

But Go cannot create DLLs yet (see issue #11058 for details). And the plan proposed on issue #11058 is still not clear. And the plan is based on using mingw - mingw runtime might not work with your program. And I hope you've heard about downsides of using cgo - http://dave.cheney.net/2016/01/18/cgo-is-not-go - I can add more.

Perhaps you reconsider using standalone Go built executable. You can run it as a Windows service, if that helps any.

Alex

[haxwagon]

The thought is that while cgo/go cannot build dlls, a static library should be linkable INTO one. The only limitation (to my knowledge) is getting a compatible set of object code in that go c-archive. Once you have that, it's fairly trivial to link it into a dll.

Personally, I'd like to see our architecture be more akin to chrome where there is a main process which essentially becomes an launch controller for slave processes (where this standalone go exe would live), but it has been a nonstarter for given architectural constraints. Many in the org want to use Go as a common, first-class language here. I'm looking to take that momentum into some new products/tech spaces.

To do that I just need a solution for this last issue :-/

I'd be good not using cgo at all, but the sqlite3 driver in go is amalgamated c. If only there was a pure go sql impl.

[alexbrainman]

The thought is that while cgo/go cannot build dlls, a static library should be linkable INTO one. The only limitation (to my knowledge) is getting a compatible set of object code in that go c-archive. Once you have that, it's fairly trivial to link it into a dll.

If you know what to do, why don't you try and build what you want.

If you did try to build something, and are having problems, then you need to provide more details about what you did and what worked or not worked.

If only there was a pure go sql impl.

In my pre Go life I used sqlite3.dll to access sqlite functionality. I am certain it can be done with pure Go today. This is obviously "windows only" solution. And you would have to copy sqlite3.dll together with your Go executable everywhere.

Alex

[AlekSi]

Support building Go code into dll (which can be called by vs2003 compiled
code) is fine, but I highly doubt that we are going to support using
CC=cl.exe to build cgo code.

Is there an issue for that (support of cl.exe in cgo)? Can't find one.

[alexbrainman]

Is there an issue for that (support of cl.exe in cgo)?

I don't remember anyone asking for it.

Alex

[qmuntal]

Is there an issue for that (support of cl.exe in cgo)? Can't find one.

See #20982. I'll close this issue as duplicated.