Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
twoboxen opened this issue Apr 11, 2016 · 10 comments

Comments

Projects
None yet
6 participants
@twoboxen
Copy link

commented Apr 11, 2016

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 bradfitz added this to the Unreleased milestone Apr 11, 2016

@bradfitz bradfitz changed the title How to integrate go (via cgo) with MSVC2003 project? x/mobile: How to integrate go (via cgo) with MSVC2003 project? Apr 11, 2016

@bradfitz

This comment has been minimized.

Copy link
Member

commented Apr 11, 2016

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.

@twoboxen

This comment has been minimized.

Copy link
Author

commented Apr 11, 2016

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

@bradfitz bradfitz changed the title x/mobile: How to integrate go (via cgo) with MSVC2003 project? runtime/cgo: How to integrate go (via cgo) with MSVC2003 project? Apr 11, 2016

@bradfitz bradfitz added the OS-Windows label Apr 11, 2016

@bradfitz bradfitz assigned alexbrainman and unassigned crawshaw Apr 11, 2016

@bradfitz

This comment has been minimized.

Copy link
Member

commented Apr 11, 2016

Sure. To @alexbrainman then.

@twoboxen twoboxen changed the title runtime/cgo: How to integrate go (via cgo) with MSVC2003 project? runtime/cgo: How to integrate go (via cgo) with MSVC2013 project? Apr 11, 2016

@minux

This comment has been minimized.

Copy link
Member

commented Apr 11, 2016

@twoboxen

This comment has been minimized.

Copy link
Author

commented Apr 11, 2016

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

This comment has been minimized.

Copy link
Member

commented Apr 12, 2016

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

@twoboxen

This comment has been minimized.

Copy link
Author

commented Apr 12, 2016

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

This comment has been minimized.

Copy link
Member

commented Apr 14, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Jul 5, 2016

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

This comment has been minimized.

Copy link
Member

commented Jul 6, 2016

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

I don't remember anyone asking for it.

Alex

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.