OpenXcom Forum
Contributions => Programming => Topic started by: JDarthenay on March 28, 2016, 06:21:57 pm
-
Hello,
I have already built the project three or four years ago, and I remember I was stuck with 32-bits building because I was unable to build SDL1.2 by myself.
I have just installed a Mingw64 set which includes a 64-bit SDL2 already compiled. May I try building openXCom with it, or is SDL1.2 mandatory?
Sorry because my question seems a bit noob-like :-\
-
for now 1.2 is required, but some branches switch to 2.0 because it support android.
-
So, what should I do ? Use a SDL2 branch or try to build a 64-bit SDL1.2?
Edit: My bad, it seems now there is a 64-bit runtime available for download. I guess I will try using it first.
-
Oh my god, I spent this whole f***ing day to try to find how to build SDL 1.2. All that to generate this damn stupid 17Ko libSDLmain.a file. Not even sure I succeeded, all that I have done so far is a black screen test program... Anybody would know a good hello world SDL 1.2 program? I don't know why I am not even finding this.
-
Another noob here, so maybe a stupid comment, but...
I compiled OpenXcom under Linux two days ago for the first time using guide on https://ufopaedia.org.
It was super easy.
And yesterday I even compiled a windows EXE under Linux, using Mingw-w64 (on 32-bit Kubuntu btw.).
That was a bit more complicated for a noob, but no rocket science.
In both cases it was either a pre-compiled sdl, or the cmake+make did everything for me... I don't even know.
So, the questions:
- why do you want to compile it yourself?
- isn't the official guide enough?
- do you want it only because of 64bits? if so, just saying you won't get any benefits from it compared to 32bits
-
So, the questions:
- why do you want to compile it yourself?
Because I was unable to find the file SDLmain.a in a 64-bit version.
- isn't the official guide enough?
Which official guide? :o
If you speak of SDL 1.2 official guide it was saying me to use MSys2 (or MSys, I am not sure) and Avast warned me he was putting Msys2 executable in quarantine because they had malwares so I uninstalled Msys2 and tried doing it with Cygwin. Maybe I was successful.
- do you want it only because of 64bits? if so, just saying you won't get any benefits from it compared to 32bits
Maybe you're right, but I remember not being able to build openXCom in 64-bits 4 years ago even though I succeeded in 32-bits, and I was wondering if I would succeed on doing it this time.
-
Which official guide? :o
I used this one: https://www.ufopaedia.org/index.php/Compiling_with_CMake_%28OpenXcom%29
Basically:
0. git clone https://github.com/SupSuper/OpenXcom.git
1. cd OpenXcom
2. sudo get-apt install .... all dependencies as listed here: https://www.ufopaedia.org/index.php/Compiling_%28OpenXcom%29#Linux.2FBSD
3. mkdir buiild
4. cd build
5. cmake ..
6. make
Done.
-
Those are excellent instructions, if you are on a (Debian derivative) Linux box.
But the post title states building under windows ;)
-
OMG.... how could I miss that!
... if you need me, I'll be in the corner of shame.
-
I won't blame you for not reading the new title I put one hour ago ;D
-
There's also a guide for MinGW: https://www.ufopaedia.org/index.php/Compiling_with_MinGW_(OpenXcom) (https://www.ufopaedia.org/index.php/Compiling_with_MinGW_(OpenXcom))
Although it's 32-bit, not 64-bit, but the steps shouldn't be too different. CMake might also be able to generate a MinGW-configured Makefile.
-
Speaking of that... I think it's me who wrote it ::)
-
It's not necessary to answer to my post. Just interesting.
What is a point of 64 bit version of openxcom? You don't need to use more than 4 GB at once of RAM. You don't really need a performance gain over 32 bit version like modern games with heavy physics and graphics. You can run 32 bit version without a problems in 64 bit version and also in 32 bit version of windows. So what is a really point of 64 bit version of openxcom? I don't understand.
-
Like I said sooner, the true reason is I failed in the past and I hope I can succeed now.
Also I could say we could need it if someone creates a custom build with a lot more stuff requiring a lot of memory, but this would obviously be mostly bad faith.
-
For mingw (with msys) build I used this makefile:
# Directories and files
OBJDIR = ../obj/
BINDIR = ../bin/
SRCS_SDL = /C/MinGW/include/SDL/
SRCS_BOOST = ../../lib/boost/
SRCS_YAML = ../../lib/yaml-cpp/
SRCS_YAML_CPP = $(wildcard $(SRCS_YAML)src/*.cpp $(SRCS_YAML)src/contrib/*.cpp)
SRCS = $(wildcard *.cpp */*.cpp */*/*.cpp)
OBJS = $(patsubst %.cpp, $(OBJDIR)%.o, $(notdir $(SRCS))) $(patsubst %.cpp, $(OBJDIR)yaml/%.o, $(notdir $(SRCS_YAML_CPP)))
BIN = OpenXcom
# Compiler settings
CXXFLAGS ?= -Og
CXXFLAGS += -Wall -std=gnu++11
CXXFLAGS += -I$(SRCS_YAML)include -I$(SRCS_BOOST) -I$(SRCS_SDL)
LIBS = -lshlwapi -lws2_32 -lopengl32 -lglu32 -mwindows -lmingw32 -lpthread -static -static-libstdc++ -lwinmm -lSDL_gfx -lSDL_mixer -lSDLmain -lSDL_Image -lSDL.dll -lm -luser32 -lgdi32 -lwinmm -ldxguid -lDbgHelp
# Rules
all: $(BINDIR)$(BIN)
$(BINDIR)$(BIN): $(OBJS)
$(CXX) $(OBJS) $(LDFLAGS) $(LIBS) -o $(BINDIR)$(BIN)
$(OBJDIR)%.o:: %.cpp
$(CXX) $(CXXFLAGS) -c -o $@ $<
$(OBJDIR)%.o:: Basescape/%.cpp
$(CXX) $(CXXFLAGS) -c -o $@ $<
$(OBJDIR)%.o:: Battlescape/%.cpp
$(CXX) $(CXXFLAGS) -c -o $@ $<
$(OBJDIR)%.o:: Engine/%.cpp
$(CXX) $(CXXFLAGS) -c -o $@ $<
$(OBJDIR)%.o:: Engine/Scalers/%.cpp
$(CXX) $(CXXFLAGS) -c -o $@ $<
$(OBJDIR)%.o:: Engine/Adlib/%.cpp
$(CXX) $(CXXFLAGS) -c -o $@ $<
$(OBJDIR)%.o:: Geoscape/%.cpp
$(CXX) $(CXXFLAGS) -c -o $@ $<
$(OBJDIR)%.o:: Interface/%.cpp
$(CXX) $(CXXFLAGS) -c -o $@ $<
$(OBJDIR)%.o:: Menu/%.cpp
$(CXX) $(CXXFLAGS) -c -o $@ $<
$(OBJDIR)%.o:: Mod/%.cpp
$(CXX) $(CXXFLAGS) -c -o $@ $<
$(OBJDIR)%.o:: Savegame/%.cpp
$(CXX) $(CXXFLAGS) -c -o $@ $<
$(OBJDIR)%.o:: Ufopaedia/%.cpp
$(CXX) $(CXXFLAGS) -c -o $@ $<
$(OBJDIR)yaml/%.o:: $(SRCS_YAML)src/%.cpp
@mkdir -p $(OBJDIR)yaml
$(CXX) $(CXXFLAGS) -c -o $@ $<
$(OBJDIR)yaml/%.o:: $(SRCS_YAML)src/contrib/%.cpp
@mkdir -p $(OBJDIR)yaml
$(CXX) $(CXXFLAGS) -c -o $@ $<
clean:
rm -f $(BINDIR)$(BIN) $(OBJDIR)*.o
.PHONY: all clean
Its need src of yaml-cpp and precompiled SDL libs (if I recall correctly from main page links). With new version yaml-cpp you could drop `boost` from it.
-
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...
-
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...
-
As long as it is not version 0.5.2 you should be ok.
-
If you have fresh sources then 0.5.3 should work too.
-
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
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
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...
-
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.
-
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?
-
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?
-
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.
-
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.
-
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.)
-
I am having a lot of compilation errors due to missing standard headers such as:
#include <algorithm>
#include <cmath>
Is there a gcc option I am missing? Or Was I wrong to check out the v1.0 tag?
-
I am having a lot of compilation errors due to missing standard headers such as:
#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.
-
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.
-
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.
-
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.
Ok, no problem, I linked with SDL.dll, no worries!
By the way I am happy I did not uninstall my previous MinGW-64 executables because using GNU Make 3.82.90 instead of GNU Make 4.0 solved my problems.
-
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.
What is real difference between recompiling dll and exe? Every problem that can affect exe can affect dll too. New dll can be incompatible with old dll etc.
Sometimes recompiling one dll could be harder that recompiling whole exe because it have most dependencies.
If everything is compiled from sources then all libraries will need exactly the same toolchain and have uniform dependencies (if two have lib that have common dep then it will be in same version other wise it will fail to compile).
Right now my experience with compiling OXC as stand alone exe is that my only problem is that I need linux (to run mxe), rest of dependencies are fix by 2 commands. It work for me, nightles and for Meridian.
-
DLL and exe are similar issue, but at least, once the DLL and library are available, they have a chance to be forward compatible for many years.
For example SDL_image (of SDL1) is a pain to compile, with dependencies :
- libpng
- which requires zlib
- libjpeg
- tiff
- (more?)
Once you manage to determine correct versions which are all compatible with each other, the resulting library and DLL are precious : They are compatible with any program which use SDL_image, no matter if it was written (or compiled) in 2006 or 2016, because the API hasn't changed ever. This is one less problem to worry about.
-
DLL and exe are similar issue, but at least, once the DLL and library are available, they have a chance to be forward compatible for many years.
For example SDL_image (of SDL1) is a pain to compile, with dependencies :
- libpng
- which requires zlib
- libjpeg
- tiff
- (more?)
This is a good thing I did not have to compile 64-bit SDL_image unlike SDL...
-
Please, people : DLLs work.
In theory, and for people who can compile them, yes.
In practice, I had to switch to single exe, because people just couldn't run the game. Since then, no issues.
-
@Yankes
Where did you find about the "-static-libstdc++" linker option?
I tried "gcc --help" and "ld --help" but I find nothing about this option...
-
@Yankes
Where did you find about the "-static-libstdc++" linker option?
I tried "gcc --help" and "ld --help" but I find nothing about this option...
https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
-
https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
I wonder why I can't see that with 'ld --help'...
They say it has no effect if '-shared' is used and you use them both... So no reason to keep it, right? Except maybe if you sometimes build without '-static' but want to keep '-static-libstdc++'.
-
I wonder why I can't see that with 'ld --help'...
They say it has no effect if '-shared' is used and you use them both... So no reason to keep it, right? Except maybe if you sometimes build without '-static' but want to keep '-static-libstdc++'.
probably yes
-
@Yankes I just discovered the "vpath" directive in makefiles. Why don't you use it to have only one pattern rule?
-
@Yankes I just discovered the "vpath" directive in makefiles. Why don't you use it to have only one pattern rule?
My knowledge of make is basic, I did not even write it, I only modify to work for me. Because building system is not my focus, if it work I can leave it as is even if it not perfect. Bigger problem for me is cmake and VS project because each time I add some file I need update them manually. I don't have this problems with makefiles.
-
Indeed, you need to update your makefile only if someone add a directory in sources. But using vpath it seems it won't even be necessary, only need to update it if someone increases the max depth in src directory.
-
If you want to use it you need to add this line after your $(SRC) definition:
vpath %.cpp $(sort $(dir $(SRCS)))
You can then remove all your compiling commands but the first one:
$(OBJDIR)%.o:: %.cpp
$(CXX) $(CXXFLAGS) -c -o $@ $<You will end with two rules instead of 13 for openXCom core.
And to avoid polluting yaml-cpp building rules you add after openXCom rule:
vpath %.cpp
-
My knowledge of make is basic, I did not even write it, I only modify to work for me. Because building system is not my focus, if it work I can leave it as is even if it not perfect. Bigger problem for me is cmake and VS project because each time I add some file I need update them manually. I don't have this problems with makefiles.
Ahhh! I feel stupid, I completely forgot you told me that! My Push Request failed automatic build check because I added a file and linking failed! What do I have to do to fix it?
-
Looking on https://travis-ci.org/SupSuper/OpenXcom/jobs/127037699 I see that build is probably generated from CMakeLists.txt
To fix it you need add your file there too.
-
That will permit to pass the automatic check I failed, but it would be even better if I could also add it in MVS project as most Windows users use it... Is there anything else to update?
-
`pch.h` if you add new headers. This is used by precompiled headers for VS but I don't know if anyone is using it right now.
-
Are you sure there is only one file such as this one?
I see only header files from "Engine" and "Interface" folders.
-
Are you sure there is only one file such as this one?
I see only header files from "Engine" and "Interface" folders.
AFAIK whole point of pch is having only one for whole project. Why only this folders? Maybe because this is most common part. Better ask person who create this file (probably SupSuper) for more accurate answer.
-
Yes, let's wait for his answer.
By the way Supsuper, could you move this topic to the development forum? Actually, it would be more its place.
-
My knowledge of make is basic, I did not even write it, I only modify to work for me. Because building system is not my focus, if it work I can leave it as is even if it not perfect. Bigger problem for me is cmake and VS project because each time I add some file I need update them manually. I don't have this problems with makefiles.
CMake supports wildcards, but apparently developers don't like it. :P It would make my job easier as well but I'd rather not touch what I'm not experienced with.
AFAIK whole point of pch is having only one for whole project. Why only this folders? Maybe because this is most common part. Better ask person who create this file (probably SupSuper) for more accurate answer.
The point of pch is to precompile headers that rarely change, this is the system/language headers and the Engine/Interface stuff in OpenXcom's case. Adding every header would just force a rebuild on every change.
I believe it's only used by MSVC and Makefile.pch though, and it's usually disabled because it tends to hide "include errors" on some compilers.
-
CMake supports wildcards, but apparently developers don't like it. :P It would make my job easier as well but I'd rather not touch what I'm not experienced with.
If with wildcards you mean GLOB please take into account the cmake devs advice against it for generating a list of source files.
See cmake documentation (https://cmake.org/cmake/help/latest/command/file.html#command:file) and check the note halfway down, which reads:
We do not recommend using GLOB to collect a list of source files from your source tree. If no CMakeLists.txt file changes when a source is added or removed then the generated build system cannot know when to ask CMake to regenerate.