Running Go programs under Wine

[Michael Tiller]

All,

  I posted some time back about cross-compiling Windows programs from Linux including CGO support.  The good news is, this seems to work well.  I've compiled some fairly sophisticated programs this way and then run them on Windows machines and they seem to work well so far.

  The bad news is...I'm having some trouble going the other way.  I've compiled EXEs under Windows and then tried to run them under WINE (on Linux) and they don't work.  Even an extremely simple program like this:

package main

import (

    "net/http"

    "log"

)

func main() {

resp, err := http.Get("http://golang.org/pkg/net/http/")

log.Printf("resp = %v", resp)

log.Printf("err = %v", err)

}

when compiled under Windows (real Windows, or cross-compiled from Linux) won't run under WINE.  In fact, in my limited testing, it seems as though this is related to sockets because it impacts programs that act both as web clients or web servers.

  Now both compilations methods seem to leverage GCC and I'm wondering if somehow this is to blame.  Is it possible to build with another compiler?  (MSVC?)  My hope is to get a tool chain (under "real" Windows) that can build exes that will run under WINE (because I need to link DLLs into the program but I want to run them on a Linux clusters...it's complicated :-)).

  Any suggestions would be greatly appreciated.

--

Mike

[minux]

On Thu, Mar 5, 2015 at 7:50 PM, Michael Tiller <michael...@gmail.com> wrote:

I've compiled EXEs under Windows and then tried to run them under WINE (on Linux) and they don't work.  Even an extremely simple program like this:

package main

import (

    "net/http"

    "log"

)

func main() {

resp, err := http.Get("http://golang.org/pkg/net/http/")

log.Printf("resp = %v", resp)

log.Printf("err = %v", err)

}

when compiled under Windows (real Windows, or cross-compiled from Linux) won't run under WINE.  In fact, in my limited testing, it seems as though this is related to sockets because it impacts programs that act both as web clients or web servers.

  Now both compilations methods seem to leverage GCC and I'm wondering if somehow this is to blame.  Is it possible to build with another compiler?  (MSVC?)  My hope is to get a tool chain (under "real" Windows) that can build exes that will run under WINE (because I need to link DLLs into the program but I want to run them on a Linux clusters...it's complicated :-)).

No, to compile cgo, gcc is required, and msvc can't be used.

Which version of Go are you using? Before Go 1.4, 64-bit windows Go binaries doesn't work at all

on wine (#8174).

Because wine is supposed to emulate Windows, so i tend to think this is a wine problem and it's

pretty low priority for Go (The windows port targets real windows, not wine.)

If you debug the problem and found it's indeed Go's problem (see #8174 for an example where a

perfectly working program on windows could have problems when running inside wine), please

feel free to file an issue. But I guess just filing issue that networking Go programs don't work under

wine will be closed immediately.

[Michael Tiller]

For those who are interested, I filed a bug report with the Wine people today:

https://bugs.winehq.org/show_bug.cgi?id=38636

This has really been a pain for me, architecturally.  So I thought I should at least report it.  I'm not sure how much attention it will get from the Wine people.  It *is* clearly a Wine problem since I'm not able to duplicate the issue under Windows, Linux or OSX and I see the same issue for wine under both OSX and Linux.  So the ball is in their court.  But it really is a shame that Go programs can't run under Wine.

P.S. - For anybody wondering why I'm not just compiling for Linux or OSX, it is because I need to load Windows DLLs under Linux and this was a pretty simple way to do that.  The approach works fine under native Windows, it is just that Wine refuses to run Windows Go programs (and, as the example I posted show, it has nothing to do with Windows DLLs).

--

Mike

[Taru Karttunen]

On 24.05 07:05, Michael Tiller wrote:
> For those who are interested, I filed a bug report with the Wine people
> today:
>
> https://bugs.winehq.org/show_bug.cgi?id=38636

Have you tried whether setting a higher
runtime.GOMAXPROCS works as a workaround
for you?

I remember running some Go stuff in the past with
Wine.

- Taru Karttunen

[Michael Tiller]

I tried setting GOMAXPROCS to 4 and 40.  Neither made a difference over the default (which was 1).  It still hangs.

But thanks for the suggestion.

--

Mike

[Brad Fitzpatrick]

This Wine bug is a dup of a dup.

First Go dup was https://bugs.winehq.org/show_bug.cgi?id=38272

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Tiller]

I saw that bug already when I searched for similar issues.  But I didn't make any connection between them.  So you think the hanging is due to a request for time that happens during the Get request?  Is this just a suspicion or do you know for sure if this is the cause?

--

Mike

[Brad Fitzpatrick]

I'm 99% sure but don't know for sure.

[Michael Tiller]

I wanted to test this concretely.  So, I tried to revert that change in the time API that seems to have triggered these issues.  But, unfortunately, the runtime/os_windows.c file has changed a bit since then and my attempts just met with seg faults.  I'm probably not enough of an expert in Windows APIs, pragmas, etc. to properly revert it.  I was hoping to confirm that this was the underlying issue, but it remains unproven.

--

Mike

[Michael Tiller]

Here is an additional data point.  I went back and built go-1.3.3 (which predates the KSYSTEM stuff).  I can confirm that my test program runs fine under Wine in that case.

I assume the plan with Go 1.5 is to continue using the KSYSTEM approach?  I'm assuming nobody wants to add a workaround just for Wine.  Are there any reasonable compromise approaches for which a pull request might be accepted so that Wine works with Go > 1.3.3?

--

Mike

[Nathan Fisher]

Perhaps a silly question and I might be missing some of the nuance here but why? From an academic stand-point I can appreciate the desire to see if it works but it isn't immediately clear the benefit of maintaining compatibility. Why not build a binary for *nix directly instead of running it through wine? Is there some other tie-in that is dependent on Windows (e.g. UI)? Is this for efficient local testing under a *nix OS?

--

[Michael Tiller]

On Tuesday, May 26, 2015 at 8:25:38 AM UTC-4, Nathan Fisher wrote:

Perhaps a silly question and I might be missing some of the nuance here but why? From an academic stand-point I can appreciate the desire to see if it works but it isn't immediately clear the benefit of maintaining compatibility. Why not build a binary for *nix directly instead of running it through wine? Is there some other tie-in that is dependent on Windows (e.g. UI)? Is this for efficient local testing under a *nix OS?

From earlier in the thread (part I had trimmed from my last reply):

[Nathan Fisher]

Apologies for missing that. :/

Could you wrap the DLL with a thin API that provides a named pipe as an interface and is compiled with MinGW or MSVC?

[Michael Tiller]

On Tuesday, May 26, 2015 at 9:48:09 AM UTC-4, Nathan Fisher wrote:

Could you wrap the DLL with a thin API that provides a named pipe as an interface and is compiled with MinGW or MSVC?

Yes.  That is similar to what I did.  But architeturally, it was getting really ugly spawning processes and debugging the whole thing.  Now that I know I can run my stuff under Wine if I simply use Go 1.3.3, I think I'll be OK.  But my concern is that some of my dependencies might depend on 1.4.x or 1.5.x in the future and then I'll be in a bind again.

Technically, the bug isn't a bug in Go, it is a bug in Wine.  But the patches proposed previously have never been incorporated.  So I suspect this issue will continue to exist in Wine going forward.  So it would be nice if there was some reasonable way to refactor the Go code so that it could support Wine without it being a "hack".  But I'm not sure if such an approach really exists.

--

Mike

[brainman]

There is no plan to change runtime to accomodate WINE. I don't see anyone but you is affected. Maybe you can create local change and use it yourself. It would be a matter of reimplementing what old code use to do. It should not be hard.

Alex