I am reporting here my experience with compiling TheDarkMod from sources on Linux. I am going to attach some patches, but beware that especially the ones related to build may be specific to the system.I have used a Gentoo Linux distribution, with multilib enabled (that means that I have a lot of libraries compiled also in 32 bit version).Relevant packages:GNU compiler: 5.4.0Boost libraries: 1.62.0The Dark Mode: SVN trunk (2.06+, last commit: 6731, Dec 15, 2016). Finally, I am new to this program and I have gone mostly from scratch, likely ignoring a big deal of lore that may demonstrate some of this as obsolete, non-optimal or plain wrong and dangerous. I'll try to catch up with the threads developing on the subject. I downloaded the sources with:
git svn clone --stdlayout https://svn.thedarkmod.com/publicsvn/darkmod_src thedarkmod
git tag FromSVN # to keep track of my own changes
(because I am the GIT type), and it took long. Nothing I am writing here depends on using GIT instead of SVN anyway. First, I should have applied immediately NightStalker's patch. I didn't, and I regret. It's from this forum, at http://forums.thedarkmod.com/topic/18544-time-saver-build-fix-for-sconslinux-compilation. Also, I did some tuning on the build scripts, that are good for general purpose but not for distribution (the distribution plays safe and assumes Pentium3). I enabled as many CPUs as available and the "native" instruction set (build_tuning.patch.txt). IDLib tries to forward-declare std::basic_string, which is a standard C++ class; unfortunately its declaration is an implementation detail, and the one in PUGIXML turns out to be incompatible with the one shipped by GCC:
error: reference to ‘basic_string’ is ambiguous
std::basic_string<char, std::char_traits<char>, std::allocator<char> > PUGIXML_FUNCTION as_utf8(const std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >& str);
And the system string class from GCC 5 is different from the one that was used to build the Boost libraries that are shipped. Sadly, the only thing I could manage was to hard-code the system Boost libraries in the build paths. In my case they are at /usr/lib32, so the magic took the form of:
grep -r -l -e 'lib/libboost' * | xargs sed -i -e 's@/usr/local/lib/libboost\(.*\).a@/usr/lib32/libboost\1.so@g' -e 's@#.*linux/boost/lib/libboost\(.*\).a@/usr/lib32/libboost\1.so@g'boost_link.sh.txt (note the "/usr/lib32/" path in two places). This, and changing PUGI header (pugi_strings.patch.txt) did the job. Now, there are linking problems with duplicate definitions. I really do not understand how that thing was supposed to work, but anyway I changed the definition of INLINE for GCC so that it avoids emitting multiple definitions for the same functions. Also I had to manually fix a couple of places for the same reason (inline.patch.txt). Next, a recent commit added a source file (idlib/geometry/RenderMatrix.cpp) but it did not add it to the source list for Linux build. There is also some piece that is Windows specific and that needs to be disabled (RenderMatrix_in_Linux.patch.txt). After this, running ./linuxBuild.sh produces gamesx86.so and thedarkmod.x86, which I copied manually into the directory where I had a downloaded installation (2.04), and that makes it a 2.06. The updater has still Boost link problems, so I use the shipped one. Just that. Now compilation works to me all the way from commit 6600 to 6731, with some exceptions here and there. The first commit works well enough that I could actually start playing Saint Lucia. The latter, though, is buggy in that my character is always considered in deep darkness: convenient for him, but not for my gameplay. More about this in another post, I guess. If you want to give these patches a try, you can run
patch -p1 < patchname.patchin the main source directory (the attached patches should be renamed, with .txt removed; the shell script operates the substitution above).