devel_glfw3.1: MinGW version incompatabilities

[slimsag]

Hey all,

I think there is a bug in Go somewhere causing incompatibilities with different MinGW versions (at least for MinGW-W64). Building a project using this package with certain MinGW versions causes the link process on windows to spout a bunch of errors.

I did test a bunch of different MinGW prebuilt binaries -- and I came up with these results:

MinGW binaries that do not work:

• x86_64-4.9.1-posix-seh-rt_v3-rev0 (from http://sourceforge.net/projects/mingw-w64/)
• x86_64-4.8.3-posix-seh-rt_v3-rev0 (from http://sourceforge.net/projects/mingw-w64/)

MinGW binaries that do work:

• x86_64-4.8.1-posix-seh-rt_v3-rev2 (from http://sourceforge.net/projects/mingw-w64/)
• tdm64-gcc-4.8.1-3.exe (from http://tdm-gcc.tdragon.net/download)

So it seems only GCC 4.8.1 works from my naive perspective. But I'll try to dig further and create an minimalistic example later on.

For an example today, try building hello.go inside the github.com/ajhager/engi/demos folder. It produces errors like this.

(Note: the issue started out here but everything important I have written here -- as that is just a mirror.)

[phase5]

this does not work for me:
x86_64-4.9.1-win32-seh-rt_v3-rev1

[slimsag]

@phase5 Thanks for letting me know. At this time I believe only (MinGW) GCC 4.8.1 works. I'll have to see if I can create a tiny reproducible case and submit this as an issue to Go itself.

Please star http://golang.org/issue/4069 if you care about this. There is a good chance that if that issue is solved it will solve this issue (among many other linker problems on Windows).

[tapir]

Any updates on this?
I think we should really have solution for this before releasing 3.1 which is I think getting closer if you look at glfw.org

[slimsag]

Any updates on this?

Sorry for the late response. I've spent the morning debugging the issue further. It can be reproduced with a very simple program like so:

package main

import (
    _ "import/path/to/glfw3"
)

func main() {
}

From what I have found so far, it seems somehow directly related to lines like:

_GLFW_REQUIRE_INIT_OR_RETURN(NULL);
_GLFW_REQUIRE_INIT();

More soon.

[slimsag]

I've just filed Go issue 8811 with a minimal (5 files, 47 lines in total) example case. At this point I don't think that we can do anything more. I am not familiar with the internals of the Go linker which is where I believe this issue is happening.

I hope the issue will be resolved before Go 1.4 or that someone else will find a workaround for it, but at this point I don't know what else I can do to resolve it.

[tapir]

I must say this is a showstopper. I hope they can fix it before GLFW release.

Thanks for the effort

[tapir]

I'm glad that Go team fixed this issue. Shall we close or test first?

[tapir]

Also let's not forget to add a line in the README for the minimum Go version required (In this case etiher 1.3.4 or 1.4)

[slimsag]

Shall we close or test first?

I did verify that the bug is fixed (not with go-gl/glfw3 sources directly though). I don't think any further testing is needed.

Lets close this once we modify the README:

Also let's not forget to add a line in the README for the minimum Go version required (In this case etiher 1.3.4 or 1.4)

I don't think there is a Go 1.3.4? Anyway I think the README should state:

• Go 1.4 is required (otherwise you must use MinGW v4.8.1 exactly, see Go issue 8811).

[dmitshur]

That should be a Windows-only note, right?

[slimsag]

That should be a Windows-only note, right?

Yeah -- sorry. It should be:

• Go 1.4 is required on Windows (otherwise you must use MinGW v4.8.1 exactly, see Go issue 8811).