cgo on Windows + cl.exe?

[Ross Light]

Hey Windows gophers out there,

I have a friend who recently wanted to try out Go with some OpenGL code he was working on.  I showed him my fork of Go-OpenGL working on my Linux machine and he was impressed.  He wanted to get it to work on Windows.

After a weekend of fiddling with build settings, we came to the conclusion that the Windows binaries wouldn't work with cgo.  We recompiled Go from source with MinGW, but cgo still gave linker errors when trying to link with OpenGL/GLU/GLEW.  The problem seems to be that the libraries are compiled and linked with cl.exe, the Visual Studio compiler, and from what I understand, MinGW doesn't like that.

I know embarrassingly little about the Windows build environment and wasn't able to help him much.  Is there something wrong we did in our approach, or is it just infeasible to try using cgo with non-MinGW-built libraries yet? (I'm not trying to reopen the "Go binary distributions" can of worms; I would just like to be better educated about the topic.)

Thanks!

Ross Light

[Brad Fitzpatrick]

Work on this is currently ongoing, from what I've noticed on golang-dev.

See http://code.google.com/p/go/issues/detail?id=3261 but there might be others.

[brainman]

Can't help you wit cgo. But if you can package your libs as dll on Windows, it is fairly easy to access them fro Go. Regardless what tools you use to produce the dll.

Alex

[Ross Light]

On Sunday, March 11, 2012 8:18:04 PM UTC-7, brainman wrote:

Can't help you wit cgo. But if you can package your libs as dll on Windows, it is fairly easy to access them fro Go. Regardless what tools you use to produce the dll.

Alex

Are you referring to the LoadLibrary/GetProcAddress functionality in the "syscall" package?  Seems like a hack if you want to use more than a handful of functions.

[minux]

On Mon, Mar 12, 2012 at 10:26 AM, Ross Light <rli...@gmail.com> wrote:

After a weekend of fiddling with build settings, we came to the conclusion that the Windows binaries wouldn't work with cgo.  We recompiled Go from source with MinGW, but cgo still gave linker errors when trying to link with OpenGL/GLU/GLEW.  The problem seems to be that the libraries are compiled and linked with cl.exe, the Visual Studio compiler, and from what I understand, MinGW doesn't like that.

Could you please provide some more details on your procedure and the linker errors?

[Ross Light]

On Sunday, March 11, 2012 8:52:52 PM UTC-7, minux wrote:

On Mon, Mar 12, 2012 at 10:26 AM, Ross Light wrote:

After a weekend of fiddling with build settings, we came to the conclusion that the Windows binaries wouldn't work with cgo.  We recompiled Go from source with MinGW, but cgo still gave linker errors when trying to link with OpenGL/GLU/GLEW.  The problem seems to be that the libraries are compiled and linked with cl.exe, the Visual Studio compiler, and from what I understand, MinGW doesn't like that.

Could you please provide some more details on your procedure and the linker errors?

 After digging around, I found out it was my own fault (as I suspected before). I'll post the full details (and a better install procedure on my fork of Go-OpenGL), but the gist is that I was trying to link with the static version of the library instead of the dynamic version.  Because the static version didn't get packed in with the package, the linking would fail when the program ran, not when the package was built.

From what I hear, just keeping a DLL in the same directory as the final executable is acceptable on Windows.

[Paulo Pinto]

This is actually the advised way of doing things nowadays, also known
as XCopy deploy.

--
Paulo

[Brandon Peters]

Ross, let me know if you and your friend are able to get any OpenGL functions past version 1.1 running on Windows.  I recently moved my Go development (using OpenGL) to Windows and I immediately hit a wall.  Well, several walls, but you seem to have worked your way through the first ones.  Go-OpenGL and gogl both fail for me, the first uses glew and the second has its own bindings but both come down to wglGetProcAddress().  That call doesn't seem to fail (returns non-NULL after properly creating a 3.3 context) but making use of the results gives me a Windows 7 appcrash:

Problem Event Name:    APPCRASH
  Application Name:   test.exe
  Application Version:    0.0.0.0
  Application Timestamp:    4f5e90b2
  Fault Module Name:    StackHash_2264
  Fault Module Version:    0.0.0.0
  Fault Module Timestamp:    00000000
  Exception Code:    c0000005
  Exception Offset:    000000f8400451c2
  OS Version:    6.1.7601.2.1.0.256.48
  Locale ID:    1033
  Additional Information 1:    2264
  Additional Information 2:    2264db07e74365624c50317d7b856ae9
  Additional Information 3:    875f
  Additional Information 4:    875fa2ef9d2bdca96466e8af55d1ae6e

About all I can do right now is set a ClearColor and Clear.

[schunk.c...@googlemail.com]

Hi,

I'm the author of GoGL (https://github.com/chsc/gogl). I haven't tested GoGL on Windows yet but it works nicely on Linux and is currently the most complete OpenGL binding for Go. It would be great if somebody is interested in porting GoGL to Windows.

wglGetProcAddress is usually the only save way to obtain valid OpenGL entry points on Windows. Have you called gl.Init() _after_ context initialization? Does the same program work on Linux? Do you use SDL or GLFW for initializing a GL context?

Christoph

[mattn]

A .lib file may often contains MSVC related codes. This could be said about mingw32. So you should generate .a from dll for mingw32 like below.

pexports glew32.dll > glew32.def

dlltool -D glew32.dll -d glew32.def -l libglew32.a

I could build on Go-OpenGL(currently moved to https://github.com/banthar/gl ?).

http://go-gyazo.appspot.com/9e19cd26c9935f23.png 

http://go-gyazo.appspot.com/b7e94960c1afdd8a.png 

http://go-gyazo.appspot.com/d84aefe98069f847.png