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.

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

Sure. To @alexbrainman then.

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?

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

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.

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

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.

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

I don't remember anyone asking for it.

Alex

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.