#245 MinGW64 creates broken GLEW.dll with -O2

[Tobias Gruetzmacher]

I'm pretty much out of ideas on this.

While trying to build GLEW with the MXE cross building environment I encountered the problem that DLLs created by MinGW32/MinGW64 don't work (crash while loading the DLL, before main from the EXE even runs) when compiled with "-O2" (See https://github.com/mxe/mxe/pull/350 for my current workaround).

I tried to debug the issue but only got from error 0xC0000005 (Generic Access visolation) to 0xc0000028 (Bad stack) by fiddeling with gflags (MS debug flag setting tool) and putting "if(a == NULL) return GL_FALSE;" at the start of _glewStrSame1 (probably not a real woraround either, the backtrace that lead to that was totally bogus).

MinGW64 Versions:
i686-w64-mingw32.shared-gcc (GCC) 4.8.2
i686-w64-mingw32.shared-ld (GNU Binutils) 2.24
MinGW32 Versions:
i686-pc-mingw32.shared-gcc (GCC) 4.8.2
i686-pc-mingw32.shared-ld (GNU Binutils) 2.24

Any ideas what I can try? Maybe this is a compiler bug?

[Nigel Stewart]

Most likely a MinGW32/MinGW64 bug of some kind.
I'll see if I can give the MingW32 toolchain a spin in this cycle...

[Nigel Stewart]

I gave MSYS2 a go today and didn't have any trouble running glewinfo.exe and visualinfo.exe. In the upcoming GLEW 2.0.0 there will be support for SYSTEM=msys (auto-detected) along with msys-win32 and msys-win64. Presumably this problem was a bug in the toolchain, long since resolved. If there is anything further on this, please file an issue on github: https://github.com/nigels-com/glew/issues