Mingw64 support

[martonperei]

I'm working on mingw support, here's what I have so far: 5f73f53

So far it works well, but there are a couple of weird oddities, which could use some input:

1. M_PI is undeclared with std=c++11 because of STRICT_ANSI
   we could use gnu++11 or define M_PI if it does not exist. For now I've defined M_PI in Common.h, but poly2tri uses M_PI too...
2. the premake platform / architecture system for the toolsets is really weird, you can't define tools.windows.x32 and tools.windows.x64 entries so I'm defining tools.x32 and x64 if the os is windows. Problem is that the clang toolset doesn't have those entries... It's not really a problem if the compiler is multilib, but mingw64 isn't.
3. I had to override the library extension from .lib to .a manually, but then override it again for the application to .exe. Feels kinda hackish.
4. Separated the SDL2 headers to generic and mingw folders because the mingw headers are different. weird.
5. Some mingw compilers leave out required libraries from linking, but defining it in ldflags.system.windows for the toolset feels out of place.

I tested with mingw64 gcc 4.8.3. Compiles and runs tutorial-01 on windows and linux cross compiling + wine.
4.9.1 crashes on Pass.cpp. I'm suspecting unordered_map...
Haven't had the time to make a full build yet to test the other modules.
Visual studio and the linux project generation still works fine so hopefully I haven't broken anything.

32-bit clang works too, but 64 bit clang has some issues (segfaults with unordered_map, other linking problems, depending on which gcc you build with...) It's kind of experimental still, so I'll probably leave it alone.

Some mingw64 distros still don't have winpthreads and have other issues, I used the versions from this for testing:
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/installer

Needs msys to work on windows so its compatible with linux cross-compiling.

[JMLX42]

Wow! Looks like you done some impressive work.
I'll let Warren answer the built system stuff.

We have made progress for cygwin, especially for the Android build.
Maybe there are some things to look for there? It should be on 'dev' soon.

[martonperei]

Don't think cygwin solves any of the issues. It would only help if minko wasn't windows compatible.
I think gcc cygwin uses mingw as the compiler too, so all the issues are still there.
Msys works fine for the build utilities (make, cp and some other things)

Though it's more than likely there's something I could use from the cygwin configurations. premake is kinda archaic.

[JMLX42]

What's the issue with windows compatibility?
I thought that the fact it works fine on linux+gcc/clang would be enough to
have mingw working :(

On Thu, Sep 11, 2014 at 8:13 PM, mindigmarton [email protected]
wrote:

Don't think cygwin solves any of the issues. It would only help if minko
wasn't windows compatible.
I think gcc uses mingw as the compiler too, so all the issues are still
there.
Msys works fine for the build utilities (make, cp and some other things)

—
Reply to this email directly or view it on GitHub
#179 (comment).

Jean-Marc Le Roux

Founder and CEO of Aerys (http://aerys.in)

Blog: http://blogs.aerys.in/jeanmarc-leroux
Cell: (+33)6 20 56 45 78
Phone: (+33)9 72 40 17 58

[martonperei]

It's just that the mingw headers are different. For example M_PI and some others are protected by ifdefs which are not present on linux and are defined as part of the default configuration.
LuaGlue does not compile with x86_64 mingw either. For some reason it's trying to specialize LuaGlueClass for unsigned long long int, which is not a class, obviously. i686 works fine.
The newest version of LuaGlue seems to compile, though it has been through a major refactor so got to update minko for that.

[warrenseine]

Ok, thanks for the update.

We'll definitely update Minko with the latest LuaGlue as we need some of its features anyway. I hope this is the only blocking issue here.

Side note: Cygwin does fix a few things for us as it runs in Bash (typically). We encountered some issues with cmd (which is used for the Emscripten build for instance) so it'd be a relief for us to drop it.

[martonperei]

LuaGlue just needed a specialization for stack... Compiles fine now.

Only using cmd for mingw to invoke premake. Msys takes care of the rest. Cygwin will work just as well too.

Pushed a couple of other commits, it fully builds now except for leap, oculus, html-overlay and angle.
The assimp example doesn't seem to be working correctly. There are no errors, but the model is not displayed. The clone example works though.

Edit: replaced the batch files with shell scripts. cmd is gone when using mingw / msys : )

Edit2: Looks like the clone example is broken. Does not run on windows, linux or mingw. mingw64 does not display the mesh in tutorial-06 and the assimp example. Mingw32 works fine.

[martonperei]

A little bit of update:
html-overlay works now in 32 bit. 64-bit crashes, but I haven't looked into it yet.
I replaced lua with luajit, everything seems to work fine apart from some script-side api incompatibilities with lua 5.2.
Luckily luaglue is compatible with the lua 5.1 c api.
The android and ios builds should be straightforward as they are documented on the luajit installation page, though I can't test them so they are not included.
I've included lua 5.1.5 as a fallback for html5, android and ios.
Tested the builds on linux gcc, windows vs, mingw (both linux and windows), os x clang, and html5 (linux and windows).

The only blocking issue for me is the fact that assimp models are not rendered on linux mingw builds. No idea where to start with debugging...
Still no leap / oculus yet, they are kinda out of my reach.

There are quite a number of commits on my fork changing a lot of stuff. I had to patch some third party dependencies too (cef, assimp), I'm not sure how comfortable you guys are with that. They should probably extracted into patches so updating isn't an issue. Merging probably won't be so simple, hopefully the coding style is fine (I tried to be consistent with the existing code)