Building openXCom in 64-bits with MinGW on Windows

[JDarthenay]

Thanks a lot Yank, your makefile is better than the one I created (I was putting each object file in the same directory as its associated source file). I think I will use it.

I was successful to build and run a small 64-bit test program using SDL and SDL_image. All dependencies I can build with CMake should be as straight as when I built them in 32-bits. The only thing worrying me now is the opengl library(ies).

Edit: Lol, I guess I am sometimes worrying for nothing. I completely forgot the opengl library was included in MinGW32. So it is also included in MinGW64...

[JDarthenay]

May I try to use yaml-cpp version 0.5.3? I don't find any post in the forum saying if openXCom works with it or not...

[R1dO]

As long as it is not version 0.5.2 you should be ok.

[Yankes]

If you have fresh sources then 0.5.3 should work too.

[JDarthenay]

Ok, so I will try with 0.5.3 this time.

I am a bit surprised when I am reading what I have done myself when I wrote the MinGW-32 building guide. I simply don't understand how it can work.

Set up SDL_gfx

Code: [Select]

LIBS = -L..\SDL-1.2.15\lib -lSDL


This should mean I was statically linking to SDL when building SDL_gfx.dll, right?

Build and run OpenXcom

Code: [Select]

LDFLAGS=(...) \bin\SDL.dll (...) ..\SDL_gfx-2.0.2\bin\SDL_gfx.dll (...) -mwindows


This should mean I link dynamically to both SDL.dll and SDL_gfx.dll...
So, why the hell did this work? Shouldn't I have SDL external functions defined both in SDL.dll and SDL_gfx.dll?

If anybody has built SDL_gfx by himself, could he tell me if he linked to SDL statically or dynamically?

Edit: I checked the two dlls in my 3 years untouched 32-bit building directories, SDL_gfx.dll is way smaller than SDL.dll, it's impossible SDL_gfx.dll contains all SDL.dll functions. I wonder what's happening exactly...

[yrizoud]

The main SDL library is always built as dynamic : it outputs a DLL, and a compiler library (.a or .lib) where each SDL function is implemented as 'find the closest SDL.DLL, and call function SDL_xxxx in it'

One reason is license : The SDL code, copyrighted by their authors and freely distributable under zlib LGPL license, stays in its own DLL.

[JDarthenay]

Thanks again for your feedback.
I am currently building SDL_gfx and effectively using the static library libSDL.a did not work, that's the dll import file libSDL.dll.a I have to use.

One reason is license : The SDL code, copyrighted by their authors and freely distributable under zlib license, stays in its own DLL.

Does that mean even though I could use libSDL.a to statically link with SDL, I have no right to distribute the executables produced this way?

[JDarthenay]

After building SDL_gfx, I tried to run the test programs. Most of them seem fine, but I have a bad result with TestImageFilter.exe. It says "Result: 0 of 27 passed OK.". Does anybody know if it is a critical problem?

[yrizoud]

though I could use libSDL.a to statically link with SDL, I have no right to distribute the executables produced this way?

If your intent is to also license your code with the GPL, or any license compatible with it, you can.
Usually, people don't, so the DLL is the way to go.

See it this way : the SDL authors have chosen to grant all users the freedom to modify SDL as they want. No matter what part of SDL you use, you are not allowed to restrict this right. The DLL system lets people use your program under your terms (can be commercial and closed-source, for example) while letting them switch the SDL.dll with one that suits their needs better.
 

[Yankes]

If I recall correctly SDL 2.0 drop LGPL and switch to more permissive license.

Overall as long you have program under GPL (in our case OXC) you can publish exe with statically linked SDL.

[yrizoud]

Yeah, but why would you do it? You're making it hard for the user.
A few years ago I had a problem with SDL 1.2 crashing whenever I pressed the key ^. The fix took about one year to reach the "stable release" (1.2.13, I think), but at least I was able to compile the DLL from the repository, and thus I could "patch" every SDL program by replacing the faulty DLL. If any program has statically linked, I would have been stuck (On Windows, even open-source programs are extremely hard to find the correct dependencies to compile. For example I've handled 3 different libPNG, incompatible with each others.)

[JDarthenay]

I am having a lot of compilation errors due to missing standard headers such as:

Code: [Select]

#include <algorithm>
#include <cmath>

Is there a gcc option I am missing? Or Was I wrong to check out the v1.0 tag?

[Yankes]

I am having a lot of compilation errors due to missing standard headers such as:

Code: [Select]

#include <algorithm>
#include <cmath>

Is there a gcc option I am missing? Or Was I wrong to check out the v1.0 tag?

fresh sources, recently this was fixed in main branch.

Yeah, but why would you do it? You're making it hard for the user.
A few years ago I had a problem with SDL 1.2 crashing whenever I pressed the key ^. The fix took about one year to reach the "stable release" (1.2.13, I think), but at least I was able to compile the DLL from the repository, and thus I could "patch" every SDL program by replacing the faulty DLL. If any program has statically linked, I would have been stuck (On Windows, even open-source programs are extremely hard to find the correct dependencies to compile. For example I've handled 3 different libPNG, incompatible with each others.)

overall GPL need that sources are available for everyone. This mean that in your case you will download custom exe, created by other that have this bug fix.

[JDarthenay]

Code: [Select]

gmake: Interrupt/Exception caught (code = 0xc0000005, addr = 0x000007FEFEF82020)

WTF?

Edit: By the way, building seems to be successful, even though I need to run "gmake all" twice each time I want to build.

[yrizoud]

overall GPL need that sources are available for everyone. This mean that in your case you will download custom exe, created by other that have this bug fix.

Available sources doesn't mean there is someone doing builds or upgrades to newer libraries.
I have had to upgrade sources and/or rebuild toolchains many times, and please believe me, it's very hard work. There can easily be an incertainty of 4 years over which version of GCC you need to use (that's 28 stable versions), Internet links go stale, nothing is forward compatible when you need it, and libraries have depencies, which have dependencies, which have depencies, which...
Please, people : DLLs work. Users don't care that there are 16 inter-dependant DLLs along with your executable, and any future maintainer will kiss you (posthumously if necessary) as you're saving them the trouble of tracking down and compiling 16 specific versions of those libraries.