Jump to content
The Dark Mod Forums

Compiling TDM 2.04 Under Linux


NightStalker

Recommended Posts

Greetings,

 

I'm looking for some information (or anecdotes or anything, really!) about the state of TDM source code compilation under Linux.

 

I've been test-compiling the latest official (2.04) TDM source code on 32-bit Slackware 14.2 and I'm a bit confused because there seems to be no way that that code would compile without at least 1 tweak under any Linux distribution (and even more tweaks under a modern Linux distribution).

 

I've also taken a look at the Doom3 (non-'BFG Edition') source code release and, frankly, the same could be said about that code release, which probably explains a lot of the TDM Linux build issues.

 

So, in summary, I cannot understand how the TDM 2.04 Linux build was ever compiled for release using the 2.04 source code provided.

 

Can anyone shed some light on this matter, please?

 

I'm considering submitting one or more patches to get past the most serious issue(s) if there's a chance that such patches will be put to good use. But before I do, I need to understand more about the history and the current state of affairs with regard to the TDM Linux builds. I don't want to duplicate efforts and/or step on anyone's toes if they're already dealing with this somehow.

 

Thanks!

  • Like 1
Link to comment
Share on other sites

I create the official Linux builds using Ubuntu 10.04. There was a time when I tried a build on a later version, but it crashed on several Linux users' boxes, so I went back to the 'safe' 10.04.

 

I can't offer any more details than that. My Ubuntu is guest-hosted on a Virtual Box setup on my Windows 7 system. Unless it totally stops working someday, I'm not inclined to spend any time on it.

Link to comment
Share on other sites

I will mention that the typical problem for Linux compiling is that you do not have a driver that supports the closed source S3TC texture codec

and\or are not using 32-bit libraries. Most distros are exclusively 64-bit and blacklist closed driver components by default.

 

http://wiki.thedarkmod.com/index.php?title=FAQ#Does_it_run_in_64_Bit_Linux.3F

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

Thanks for the input. Much appreciated, guys!

There was a time when I tried a build on a later version, but it crashed on several Linux users' boxes, [...]

Was this, by chance, discussed publicly, so that I might find more details in a search? (I've already perused the forums and read several Linux-related threads before posting, but I could have easily missed some things, hence my post here.)

 

I can't offer any more details than that. My Ubuntu is guest-hosted on a Virtual Box setup on my Windows 7 system. Unless it totally stops working someday, I'm not inclined to spend any time on it.

Understood. But is there any interest in getting things updated in the source code to support a modern Linux distribution? If not, I certainly don't want to waste my time (or anyone else's).

 

And is there anyone else compiling the source code under Linux?

 

Lastly, with no disrespect intended whatsoever, I simply cannot see how you could be successfully compiling the source code, as published, under Linux (Ubuntu 10.04 or anything else). Here's the nitty gritty (from 'sound/snd_local.h') that I was hoping to avoid getting into so soon:

// you need the OpenAL headers for build, even if AL is not enabled - http://www.openal.org/
#ifdef _WIN32
#include "../openal/include/al.h"
#include "../openal/include/alc.h"
#include "../openal/idal.h"
// broken OpenAL SDK ?
#define ID_ALCHAR (ALubyte *)
#elif defined( MACOS_X )
#include <OpenAL/al.h>
#include <OpenAL/alc.h>
#define ID_ALCHAR
#else         
#include <AL/al.h>
#include <AL/alc.h>
#define ID_ALCHAR
#endif
#include "../openal/include/efxlib.h"
Under Linux, that code will attempt this:

#include <AL/al.h>
#include <AL/alc.h>
But the 'AL' directory simply doesn't exist in the TDM 2.04 source code release (or any other, for that matter, including the Doom3 source that it came from!), so that's why I'm mystified as to how you're able to build it. Any chance you could check your Linux build tree to see if you have that same code in 'sound/snd_local.h' and if that "AL" directory exists anywhere in your build tree?

 

I will mention that the typical problem for Linux compiling is that you do not have a driver that supports the closed source S3TC texture codec and\or are not using 32-bit libraries. Most distros are exclusively 64-bit and blacklist closed driver components by default.

I'm actually well beyond that point, but I appreciate the suggestions. I've already got TDM 2.04 compiling and running under 32-bit Slackware 14.2 Linux, with GCC 5.3.0. But I have made no attempts (and don't plan in the immediate future) to use a 64-bit Linux distribution for TDM.

 

I'm just trying to help out by applying what I've learned in the process to improve the robustness of the Linux side of TDM.

 

Any further light that anyone can shed on any of this stuff, I'd appreciate!

 

EDIT: Minor grammar fix and quote format cleanup.

Edited by NightStalker
Link to comment
Share on other sites

Do you have OpenAL libraries installed?

No, I don't. Thank you for the reminder about this. I'd actually downloaded (and quickly perused but not installed) OpenAL source code several days ago but forgot about it since (other than, apparently, just those header files) it's not even required for a successful build and run of TDM 2.04, with perfect sound (AFAICT).

 

I suspect that you've hit that nail right on the head, explaining why 'grayman' had success when I had to hack that file.

 

Frankly, from what I saw, the whole "sound stuff" is a bit of a mess, code-wise. No fault of the TDM folks -- it's a mess in the original Doom3 source release, from what I've seen so far. It could stand for a big cleanup, but I suspect there's little enthusiasm for that.

 

Nevertheless, I plan to install OpenAL and start the compilation from scratch (original, unhacked, 2.04 TDM sources), just to confirm things.

 

There are other problems besides the OpenAL stuff. That one was just the most pressing to someone attempting to compile under Linux (without OpenAL, at least).

 

Anyway, with that mystery presumably solved (thanks again, 'nbohr1more'), the question remains about whether there's any appetite for all the other things that could use some updating on the Linux side.

Link to comment
Share on other sites

We probably could use a dedicated Linux coder. For the active dev team, Linux compiles and maintenance are a secondary concern compared to our main Windows userbase. Tels was the last active Coder with a primary interest in Linux code.

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

I've just done a much more thorough search of the forums and the only recurring themes I see about Linux crashes (unrelated to people's video card driver issues) seem to be primarily related to the in-game mission downloader and, to a much lesser extent, to EAX audio use. So, 'grayman', if you have any hints to offer, I'd still like to know more about any problems people had with TDM crashing when compiled under a newer Ubuntu. Maybe I could duplicate and address some of those issues. No problem if it's been too long ago to recall, though.

As for the compile issues, as expected, installing OpenAL solved the 1st Linux compile failure due to the missing headers.

I know that might seem obvious (especially in retrospect and especially to those not semi-intimately familiar with the TDM code layout), but I would argue that it's quite confusing for the TDM source code distribution to include OpenAL headers in 'openal/include' but then also require installation of the whole OpenAL library, essentially just to get a couple of the same headers, but in a different tree structure! It's unseemly, but a re-check of the released Doom3 source code shows that that's how it was done there, so TDM inherited that madness. :o

We probably could use a dedicated Linux coder. For the active dev team, Linux compiles and maintenance are a secondary concern compared to our main Windows userbase. Tels was the last active Coder with a primary interest in Linux code.

I was hoping that there might be at least 1 Linux person on the dev team who would be able to integrate some patches and maybe test things on a more mainstream Linux distribution. Lacking that, I think I'll probably just formulate a couple of simple patches for the issues that actually prevented TDM 2.04 from compiling on 32-bit Slackware 14.2, leaving some of the broader issues unaddressed for now.

Of course, if anyone else has some input on any of this, I'd still love to hear it.


Link to comment
Share on other sites

I started building releases with TDM 1.08, over 4 years ago.

 

I don't remember what the issues were when I tried later versions of Ubuntu than 10.04.

 

I can't find any references to this in the forum. The conversation might have been in a long-ago-deleted PM.

 

For now, it there are changes needed in order to build for newer Linux distros, please submit them and we'll put them into 2.06.

Link to comment
Share on other sites

I don't remember what the issues were when I tried later versions of Ubuntu than 10.04.

 

I can't find any references to this in the forum. The conversation might have been in a long-ago-deleted PM.

No problem. I still appreciate your taking time to recall and search, especially when I realize you guys probably have your hands full with 2.05 prep.

 

For now, it there are changes needed in order to build for newer Linux distros, please submit them and we'll put them into 2.06.

Wilco. The only issue is that I don't want to fix something for modern Linux distributions only to unintentionally break it for someone still running an older distribution.

 

Yesterday, I grabbed the oldest Linux distribution I could find on HDD (Xubuntu 10.10), intending to see how things would compile there. But it lacked 'scons' (and $DEITY knows what else). And the Xubuntu 10.10 repositories seem to be dormant. I didn't chase it any further than that, but maybe I'll find the motivation to try more, later on.

 

Patches should be forthcoming, but it may take a while. Lots of irons in the fire ATM....

Link to comment
Share on other sites

Your efforts would be highly appreciated NightStalker. I've been wanting to get this compiled on linux for years now. I lack the skills fix the errors I get.

 

Forum post:

http://forums.thedarkmod.com/topic/18318-compilation-error-reference-to-basic-string-is-ambiguous/

 

Bug report:

http://bugs.thedarkmod.com/view.php?id=4419

 

My system:
Linux 4.8.11-1-ARCH #1 SMP PREEMPT Sun Nov 27 09:26:14 CET 2016 x86_64 GNU/Linux
Please contact me if I can help in any way.
Link to comment
Share on other sites

@grayman:
The next time you happen to fire up Ubuntu 10.04, could you please query and report the versions of both GCC and SCons?

gcc --version
scons --version

This will help me to be sure, as closely as practical, that I'm properly targeting your build environment. With you being the official builder of the Linux releases, I'm most interested in preserving compatibility in that setup. Thanks!

Your efforts would be highly appreciated NightStalker. I've been wanting to get this compiled on linux for years now. I lack the skills fix the errors I get.

Forum post:
http://forums.thedarkmod.com/topic/18318-compilation-error-reference-to-basic-string-is-ambiguous/

Bug report:
http://bugs.thedarkmod.com/view.php?id=4419

My system:
Linux 4.8.11-1-ARCH #1 SMP PREEMPT Sun Nov 27 09:26:14 CET 2016 x86_64 GNU/Linux

Please contact me if I can help in any way.

For several reasons, I'm very glad you posted about this, Crinkelite!

For starters, I didn't encounter your referenced post while searching for Linux build/crash issues. I know that my search, although extensive, was not complete. So your post is good "extra input" for me.

Also, your mention of having difficulty building from SVN dovetails nicely with what I had planned to mention (more below).

I also very much appreciate your willingness to help out. For starters, at your next convenience, can you please report your version info (see above) for GCC and SCons? That could help in the future.

I'm slowly working my way through the issues with a good Linux compilation. I'll have more to say about that reasonably soon.

For now, suffice it to say that I will take your compilation issues as seriously as my own. I suspect we'll eventually get to the point where most folks can comfortably compile the latest TDM source code using both older and more modern Linux distributions. I've already made some (as yet unreported) progress in that direction.

All I ask is that folks give me a bit more time as I investigate this. I'm making every effort to be both careful and thorough.

Thanks again for your post, Crinkelite. It's always good to see a few fellow Linux users out there, especially ones who are interested in compiling!

@All:

Is the latest SVN code the code that will be used for 2.05? Or is there a private (presumably hidden) branch?

I'm asking because as I'm progressing, I've been solely focusing on building the TDM 2.04 source code. But late yesterday, I built against latest SVN (6720) for the 1st time.

Unfortunately, I'm encountering new build errors, on both an older Slackware distribution (13.1, circa Jun 2010, used explicitly to replicate [as closely as I easily can ATM] grayman's use of Ubuntu 10.04) and on the latest (14.2) Slackware distribution.

I was able to work around the 1st build error quickly with the addition of a compiler option. But the 2nd error encountered is different on old versus new distros. And fixing them does not look to be as easy, so I'll need some time to investigate more. I think it makes sense to open a different thread about those issues, adding to it as I encounter issues about which I have questions.

Crinkelite's conveniently-timed post nicely underscores the issue of Linux build errors in latest SVN because his build error (circa 03 Sep 2016) is one that I had not yet even encountered.

So, if the SVN is the 2.05-rc1 equivalent, then grayman will presumably have problems building the Linux 2.05 release. On the other hand, if the SVN is not the 2.05-rc1 equivalent, then there's no need for immediate concern, but the build problems will, of course, still need to be addressed in due time.

Furthermore, if latest SVN is not the 2.05-rc1 equivalent and anyone wants me to try building it on Linux, then just kindly point me to the 2.05-rc1 code.

Any/all input on this will be greatly appreciated, folks! Thanks!

Link to comment
Share on other sites

The read-only SVN is 2.06 early alpha.

 

2.05 is already branched off.

 

For 2.04 you should download the source package:

 

http://www.thedarkmod.com/sources/thedarkmod.2.04.src.7z

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

gcc:

 

gcc (Ubuntu 4.4.3-4ubuntu5.1) 4.4.3

 

scons:

script: v1.2.0.d20100117.r4629, 2010/01/17 22:23:21, by scons on scons-dev
engine: v1.2.0.d20100117.r4629, 2010/01/17 22:23:21, by scons on scons-dev
------------------------------
2.05 has already been branched from the trunk. After some fixes I needed to get from duzenko regarding source changes he made, I have no problem compiling 2.05 on my virtual Linux box. We do have a Linux crash that was reported after the load screen of any mission, which is new w/2.05. Hopefully the Linux folks can figure that out, otherwise I'll prolly have to revert the source code back to a working version.
Any improvements you make will be included in 2.06; I don't wish to make compilation changes at this late date unless they're going to fix a problem discovered during 2.05 beta that prevents the game from running on Linux.
Link to comment
Share on other sites

TDM 2.05 Beta:

 

http://forums.thedarkmod.com/topic/18525-beta-testing-205/?p=398268

 

send a PM to Bikerdude if you plan on participating.

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

gcc (GCC) 6.2.1 20160830
Scons
script: v2.5.0.rel_2.5.0:3544:95d356f188a3[MODIFIED], 2016/04/09 14:38:50, by bdbaddog on ubuntu1404-32bit
engine: v2.5.0.rel_2.5.0:3544:95d356f188a3[MODIFIED], 2016/04/09 14:38:50, by bdbaddog on ubuntu1404-32bit
engine path: ['/usr/lib/python2.7/site-packages/SCons']

Good stuff Nightstalker, I too am delighted to talk to another Linux compiler.

I don't know how much help I can be but please let me know if I can assist in any way.

Edited by Crinkelite
Link to comment
Share on other sites

send a PM to Bikerdude if you plan on participating.

Done. Thank you, good sir!

gcc (GCC) 6.2.1 20160830

Wow! 6.2.1! I guess all my "new" Slackware 14.2 installations with GCC 5.3.0 are already outdated! ;)

I don't know how much help I can be but please let me know if I can assist in any way.

You've assisted already. Many thanks!

Link to comment
Share on other sites

OK, I've finally had enough time to sort through things and do all the extensive permutations of testing that I wanted to do, to be sure things don't break for grayman and his older (Ubuntu 10.04) build setup.

Since my last post here, mostly out of curiosity, I had started down the road of trying to compile against latest SVN, but that turned out to be frustrating. For example, fixing one problem could trigger another (new!) problem. And, IIUC, there was a change that went into SVN that further broke things under Linux:

I quickly concluded that trying to build "latest SVN" would be a moving target and an exercise in frustration, so I went back to my plan:

I think I'll probably just formulate a couple of simple patches for the issues that actually prevented TDM 2.04 from compiling on 32-bit Slackware 14.2, leaving some of the broader issues unaddressed for now.

So, please find the attached 2 simple patches, both affecting headers in the DevIL (Imaging) library:
devil-1.patch.txt
devil-2.patch.txt
These 2 simple patches allow virgin TDM 2.04 code to compile successfully under 32-bit Slackware 13.1 and 14.2. As a reminder, Slackware 13.1 uses GCC 4.4.4, which is hopefully close enough to grayman's Ubuntu 10.04's GCC 4.4.3 as to not cause any issues. For the record, Slackware 14.2 uses GCC 5.3.0.

I've done the appropriate test-compiles and game test-runs to convince myself that these 2 patches should not cause major disruption, but, of course, I am not the decider as to whether these patches go into SVN. But I would semi-strongly recommend them as a way to make the Linux compiles more robust under newer versions of GCC.

These 2 patches were made against 2.04 source code, not against latest SVN, per se. But latest SVN has not changed since 2.04 in this area, so the patches effectively are easily install-able against SVN.

Oh, BTW, that OpenAL library issue mentioned earlier must still be taken into account. In other words, if you don't have OpenAL installed on your Linux setup, it will be needed, simply for access to 2 header files. On my Slackware versions, I successfully used OpenAL-Soft version 1.17.2, downloaded from the OpenAL-Soft website.

P.S. Sorry it took me so long. I was swapping HDDs to test under both OSes and I was also perpetually running out of space on one, so I decided to re-install everything on a new 200-GB HDD with 4 large partitions, allowing me much greater flexibility and ease of testing (both now and going forward). If need be, I can also now install 2 more versions of Linux for future testing.

@Crinkelite:

Given that "latest SVN" is a hard target to deal with, if you're willing, can you please try compiling against the "virgin" 2.04 source code?

I'm wondering if you'll encounter exactly the same issues that I do under 32-bit Slackware 14.2 (circa mid-2016, GCC 5.3.0, SCons 2.4.1) or if you'll encounter more and/or other build issues.

I suspect you'll have to apply the 2 patches in this post at some point, but I'd be interested in your results.

No hurry, and no need to do this at all if it's a pain.

And thanks for confirming (in that other thread) that my SCons/Linux patch works for you. For me, it's saving about 7 minutes with each and every simple code change after the 1st large/slow build, so I could/would not live without it. :smile:

Link to comment
Share on other sites

Very sorry about that, duzenko. I didn't mean to cast any aspersions on your code (or anyone else's). I just didn't have the details in my notes, other than a link to that BugTracker item as something that had aggravated the build (IIRC). Normally, I take careful notes, but this was 3 days ago and I was basically just playing around with SVN, trying to get my arms around what might need attention.

And, ATM, I cannot recall what led me to BugTracker item #4425, even after reviewing my "testing" notes. I will try to reproduce whatever I'd done that led me to that conclusion. But compiling SVN under Linux is a bit of a "fool's errand" ATM, so I hope I can properly re-trace my steps. Either way, I'll let you know what I find.

Again, sorry for the lack of supporting evidence on my previous post. :blush:

Link to comment
Share on other sites

Duzenko,

 

I searched a compilation output file I'd saved from 3 days ago and turned up these hits:

   ==> grep "error:" full-build-compile-output-slackware-14.2-SVN-trunk-1CPU.txt
      .
      .
      .
   renderer/tr_backend.cpp:623:38: error: 'use_qglGenTextures' was not declared in this scope
   renderer/tr_backend.cpp:624:49: error: 'use_qglBindTexture' was not declared in this scope
   renderer/tr_backend.cpp:643:147: error: 'use_qglTexImage2D' was not declared in this scope
   renderer/tr_backend.cpp:661:50: error: 'use_qglBindTexture' was not declared in this scope
   renderer/tr_backend.cpp:716:56: error: 'use_qglViewport' was not declared in this scope
   renderer/tr_backend.cpp:720:24: error: 'use_qglEnable' was not declared in this scope
   renderer/tr_backend.cpp:724:72: error: 'use_qglBindTexture' was not declared in this scope
   renderer/tr_backend.cpp:736:19: error: 'use_qglTexCoord2f' was not declared in this scope
   renderer/tr_backend.cpp:749:25: error: 'use_qglDisable' was not declared in this scope
Going from memory now, but I think when I searched the SVN for things related to those errors, "#4425" came up in the comments of the diff output.

 

Does any of that look familiar? If I'm off-base here, then I apologize for the confusion.

 

Or if that's still ambiguous and I need to dig deeper, please let me know. Thanks!

  • Like 1
Link to comment
Share on other sites

I am not a native English speaker so I can't always articulate right.

What I was trying to say is that I only compile TDM code on Windows and if any of it breaks Linux build then it's my problem and duty to fix.

Now this use_qglDisable is never seemingly used in TDM at least "Find all" in VisualStudio gives 0 matches.

My guess it is stumbling on calls of functions glViewport, glEnable, etc? What happens if you add a 'q' in the start, i.e. qglEnable, etc?

 

This entire 'qgl' thing is a mystery to me.

Link to comment
Share on other sites

I am not a native English speaker so I can't always articulate right.

What I was trying to say is that I only compile TDM code on Windows and if any of it breaks Linux build then it's my problem and duty to fix.

Now this use_qglDisable is never seemingly used in TDM at least "Find all" in VisualStudio gives 0 matches.

My guess it is stumbling on calls of functions glViewport, glEnable, etc? What happens if you add a 'q' in the start, i.e. qglEnable, etc?

 

This entire 'qgl' thing is a mystery to me.

OK, that's all good to know -- thank you. Give me some time to look into this a bit more.

 

My initial suspicion is that these odd GL-related names are due to some "name mangling" by the C++ compiler, which is something that I ran into with the OpenAL (audio) stuff when compiling TDM several days ago. Frankly, I'm not a big C++ guy -- I avoid it whenever I can, strongly preferring good, old-fashioned C. So I'm not the ideal person to be sorting this out.

 

I may try to revert to an SVN revision (if there is one) that still compiles successfully under (old or new) Slackware. From there, I can proceed forward until things "break" and then report with proper details. But I'm a bit "rusty" with certain SVN commands too, so please be patient! :smile:

 

Either way, I'll give it my best effort and report back here when I know more.

Link to comment
Share on other sites

Frankly, I'm not a big C++ guy -- I avoid it whenever I can, strongly preferring good, old-fashioned C.

Neither am I but the good news is most of TDM sources are as C as C++ goes.

I would really try the qgl thing first because it's easy and can actually work.

Just get the last svn rev because I did some changes in that area today.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...