MinGW instead of MSVC?

[Starkkz]

Hello, I just came to discuss the idea of switching from MSVC to MinGW (Or at least releasing MinGW builds too at part from MSVC). It might not be the best idea because some games could break if they're loading dynamic libraries.

Why do I think we should do this?
I found a site called LuaPower (https://luapower.com/), the developer of this project has released several libraries intended for LuaJIT and most of them are compatible with löve at some point. Except windows for some reason, the person whoever develops the content of this site is only willing to use MinGW as a compiler but there are libraries that just crash if you try to use their functions on the MSVC build of löve2d (even using a MinGW lua51.dll didn't help because it broke "print" and it still crashed).

I wasn't able to compile löve on MinGW because I'm a complete ignorant into compiling stuff, and I found a single topic about this which was kept to die.
viewtopic.php?f=4&t=706

Any other opinion about this? Considering the amount of libraries we'd be able to use from that site.

[bartbes]

but there are libraries that just crash if you try to use their functions on the MSVC build of löve2d (even using a MinGW lua51.dll didn't help because it broke "print" and it still crashed).

That kind of stuff tends to happen when the runtime libraries don't match.

As for compiling with mingw, the hardest part may be getting all deps together, but that's a solved problem thanks to megasource. For the most part, telling cmake to generate a makefile for mingw then using that should just work™.

[_Yank]

Yeah, I was having some problems related the SDL installation. I've installed DirectX SDK and also, dropped SDL development binaries over the mingw directory but still. I guess I'll try the megasource thingy as you said.

EDIT: Ok I tried to do what you've said, following the steps provided on, https://bitbucket.org/rude/megasource. I first faced a little problem due to the fact that mingw wasn't the first on the Path enviroment variable. After fixing that, I ran cmake -G "MinGW Makefiles" -H. -Bbuild (set the generator to be Mingw as you've said), it seemed to work and it was able to build some dependencies. Then it reached a point and returned me an error saying that it couldn't find LOVE.

Well, here are both CMakeError and CMakeOutput:
http://pastebin.com/TcyDufyE
http://pastebin.com/X27CXW8u

EDIT2: Oh nevermind, I think I used the wrong love source. Will now try with again with a clone of the minor branch from the bitbucket repository.

EDIT3: Now it returns me an error about the 1263rd line on CMakeLists.txt related to the add_move_file function.
Well, here are both CMakeError and CMakeOutput:
http://pastebin.com/P4Nmku9Y
http://pastebin.com/V9pthPDJ

Sorry if I'm doing something wrong, I mean, I know nothing about this building world.

[bartbes]

EDIT2: Oh nevermind, I think I used the wrong love source. Will now try with again with a clone of the minor branch from the bitbucket repository.

You definitely don't want to be building minor. If you want to build 0.9.2, build the default branch on the 0.9.2 tag, if you want to build the current in-development version of 0.10.0 just build default.

Well, here are both CMakeError and CMakeOutput:

It may be that I'm missing it because of their size, but I don't see failures in any of those files.

[_Yank]

I still getting the same error:

Code: Select all

-- LuaJIT: Enabled
-- Target platform: x86
CMake Error at libs/love/CMakeLists.txt:1187 (add_move_file):
    add_move_file Function invoked with incorrect arguments for function named: add_move_file

[bartbes]

Hmm, I'm not too familiar with CMake, but you could try changing 'add_move_file' on that line to 'add_move_dll', which is used everywhere else.

EDIT: It looks very much intentional, and I found the definition of add_move_file in the megasource CMakeLists, so I'm not sure why it would fail.

[_Yank]

And the problem persists.