Jump to content
The Dark Mod Forums

Compiling TDM 2.04 Under Linux


NightStalker

Recommended Posts

Hmm, sounds like you either need to abstract these to alias values or add some sorta include to tr_backend.

 

Relevant areas:

 

sys/linux/qgl_enforce.h
renderer/qgl_linked.h

renderer/qgl.h

renderer/glext.h

renderer/tr_local

renderer/RenderSystem_init.cpp

 

I think we did some initial research into moving to GLEW to make this process easier but those changes

were reverted because the overall commits were large and unstable (too much work to keep just the GLEW part).

 

Here's an old GIT with GLEW:

 

https://github.com/revelator/The-Darkmod-Experimental

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

When you have something you believe is stable, pass me the patches and I'll add them to a 2.05 src copy to see if my virtual Linux box can compile w/o problems.

 

If there are no compile problems, I'll pass the binaries back to you and anyone else testing Linux to see if the 2.05 Linux problems go away.

 

We have 12 days until the release date.

Link to comment
Share on other sites

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?

It turns out that you are right about the need for the 'q'. Why wasn't that added to start with? All of the Doom3 (non-BFG) source code I looked at seems to be consistent in using the 'q' prefix on GL-related calls, but TDM (SVN) has an inconsistent mix of with-prefix and without-prefix calls.

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

That's apparently how the Doom3 folks did it. I don't know anything about the Doom3 engine other than what I've learned in the last week, but it's probably an indication of the game code's 'Quake' heritage. At least, that's my uneducated guess. :unsure:

 

But there are a few other problems besides that one.

 

I've hacked away for hours, going back and compiling various SVN revisions. I had to go all the way back to SVN #6642, bisecting at each step, to get something that would compile on my 32-bit Slackware 14.2 setup. But although it compiles, it won't actually run the game very well. It crashes just like the 2.05-beta does -- as soon as you try to start the mission by hitting the 'Attack' key, it aborts with a segfault from a 'memcpy()' call.

 

It's actually possible to hack away and get the latest SVN (#6723) to compile too, but it crashes the same way. And I'm not going to publish that patch set because it's laden with some quick, ugly hacks that I consider inappropriate for SVN or for which I have no idea what other problems they might cause.

 

I'm pretty much out of both energy and time for now.

 

Assuming you want to release 2.05 with a working Linux build, my recommendation would be to start backing out the changes until you can get to something that both compiles and runs past the mission loading phase without crashing. Only then start re-applying the backed-out changes one-by-one, this time carefully assessing each change's impact on both Linux building and running.

 

I'm sorry that I have no more advice or any reliable patches to offer in this case. I gave it my best shot, but this is really someone else's problem to fix.

 

I will close with a friendly but strong reminder for someone to kindly apply my SCons/Linux build patch. It's a real time-saver that should not be left to fall through the cracks!

 

I'm going to be quite busy for a couple of weeks or longer, but I'll try to keep an ear on the forums to jump in with any helpful comments whenever I can. Good luck!

Link to comment
Share on other sites

But although it compiles, it won't actually run the game very well. It crashes just like the 2.05-beta does -- as soon as you try to start the mission by hitting the 'Attack' key, it aborts with a segfault from a 'memcpy()' call.

Is there a stack trace maybe?
Link to comment
Share on other sites

 

@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:

 

I get the same results with 2.04 as with the svn.

I've attached both pre and post patch logs.

 

Thanks for fixing the scons issue. I'm seeing substantial gains also.

 

I would have liked to reply earlier but I was away for the weekend.

I'm very anxious to see this get fixed so I'm quite willing to do any testing that might help.

compile_log_2.04.txt

devil_patched_compile_log_2.04.txt

Link to comment
Share on other sites

In the 2.05 beta thread, we have a report that Manjaro Linux works wherea regular Arch is failing.

I suspect that there is a library difference or driver difference there but I thought I would mention this.

  • Like 1

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

Is there a stack trace maybe?

Sorry for leaving out that detail. I'd already posted this in the beta-test thread (about the crashes on missions "Closemouthed Shadows" and "The Outpost"):

WARNING:Couldn't load sound 'player_sounds_skipcinematic.wav' using default
WARNING:Couldn't load sound 'player_sounds_teleportexit.wav' using default
WARNING:Couldn't load sound 'player_sounds_teleportstart.wav' using default
20 warnings
Bloom Kernel size is set to: Small
Using TDM's enhanced interaction

Thread 1 "thedarkmod.x86" received signal SIGSEGV, Segmentation fault.
0xb7b251c7 in memcpy () from /lib/libc.so.6

Interestingly, this is decidedly different from Baal's (Linux) crash backtrace. Wish I could offer more info. I actually tested a lot more than what my post may have implied, but I got nowhere and didn't want to clutter up my post about testing I'd done that didn't resolve the issues.

Link to comment
Share on other sites

I get the same results with 2.04 as with the svn. I've attached both pre and post patch logs.

I will take a look at your logs as soon as I can find some time. Many thanks for doing the test!

I would have liked to reply earlier but I was away for the weekend.

Not a problem at all. This data should help at some point. Thanks again!
Link to comment
Share on other sites

I get the same results with 2.04 as with the svn. I've attached both pre and post patch logs.

I took a look at your log files but I cannot give any useful advice because the errors you're seeing are completely different than the ones I saw when compiling under Slackware.

 

But I was reminded that you're trying to compile TDM under a 64-bit OS. In contrast, throughout all of my TDM testing, I've only been compiling and running it on 32-bit Linux (Slackware 13.1 and 14.2), never under 64-bit Linux.

 

Wish I had more to suggest, but, short of saying "switch to 32-bit Slackware", I don't. Sorry. :(

  • Like 1
Link to comment
Share on other sites

I took a look at your log files but I cannot give any useful advice because the errors you're seeing are completely different than the ones I saw when compiling under Slackware.

 

But I was reminded that you're trying to compile TDM under a 64-bit OS. In contrast, throughout all of my TDM testing, I've only been compiling and running it on 32-bit Linux (Slackware 13.1 and 14.2), never under 64-bit Linux.

 

Wish I had more to suggest, but, short of saying "switch to 32-bit Slackware", I don't. Sorry. :(

 

Ok so I decided to try compiling under 32 bit Linux.

I installed Ubuntu 32 bit 16.10 via qemu and attempted to compile the source.

I'll post the resulting output later tonight (when I figure out qemu's shared folder feature) but for now I'll just say that the results seem to be identical to 64 bit arch.

 

Compilation fails with while processing pugixml.hpp with "reference to basic_string is ambiguous".

Is it possible that this bug has been introduced by the pugixml project?

 

I'll do my best to get the actual logs posted later and will attempt to set up a working Slackware 32-bit environment for further testing.

 

Thanks to NightStalker for taking the time to look at the logs. I'd like to know what version of Slackware you're using so that I can try to match your environment as closely as possible.

Link to comment
Share on other sites

I'll post the resulting output later tonight [...]

So where is it?

Is it possible that this bug has been introduced by the pugixml project?

Highly doubtful. Remember... that same code compiles and runs fine for me (and grayman).

I'd like to know what version of Slackware you're using [...]

Re-read the quote of my message in your previous post for a strong hint! ;)

 

But let's be 100% clear here... What code are you trying to compile? For now, until somebody works out the broken-ness of latest SVN, I'm only "supporting" compiles against virgin 2.04 source code since that's all I've been able to both compile and run.

Link to comment
Share on other sites

NightStalker,

Can you try image_mipmapMode 0?

 

I also have this error when compiling trunk under 32-bit ubuntu:

In file included from game/script/Script_Doc_Export.cpp:26:0:
game/script/../pugixml/pugixml.hpp:1070:2: error: reference to ‘basic_string’ is ambiguous
  std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > PUGIXML_FUNCTION as_wide(const char* str);
  ^~~
In file included from game/script/Script_Doc_Export.cpp:26:0:
Link to comment
Share on other sites

NightStalker,

Can you try image_mipmapMode 0?

Gladly. I fired up TDM 2.05-beta1 (the original beta, not any of the newer ones with, AFAICT, only changes to resources, not to actual code) and started a new mission ('The Outpost').

 

The 'image_mipmapMode 0' command is accepted, but the crash that results when I press 'Attack' is the same 'memcpy()' call reported previously:

19 warnings
 Bloom Kernel size is set to: Small 
Using TDM's enhanced interaction

Thread 1 "thedarkmod.x86" received signal SIGSEGV, Segmentation fault.
0xb7b251c7 in memcpy () from /lib/libc.so.6
(gdb) 
A subsequent TDM run shows that mode 0 is actually the default on my setup, so, presumably, the 'image_mipmapMode 0' command had no appreciable effect on anything.

 

Here's a console dump, showing my query of the current, unaltered setting for MIPmapMode and showing my (redundant) action of setting it to zero:

   .
   .
   .
--------------------------------------
--- Common Initialization Complete ---
------------- Warnings ---------------
during The Dark Mod initialization...
WARNING:Couldn't load image: guis/assets/splash/launch
WARNING:file materials/tdm_epi_shader.mtr, line 425: material 'transformer_gauge' previously defined at materials/tdm_epi_shader.mtr:300
WARNING:file materials/tdm_epifire_furniture.mtr, line 35: material 'leather_chair_001' previously defined at materials/tdm_epi_shader.mtr:701
WARNING:file materials/tdm_stone_natural.mtr, line 2065: material 'textures/darkmod/stone/natural/rough_greyblue01' previously defined at materials/tdm_stone_flat.mtr:2139
WARNING:file skins/tdm_decorative_wall.skin, line 1682: skin 'curtain_purple_dull' previously defined at skins/tdm_decorative_wall.skin:1653
WARNING:file skins/tdm_gen_metal.skin, line 596: skin 'iron_flat' previously defined at skins/tdm_gen_metal.skin:103
WARNING:file sound/tdm_ai_commander.sndshd, line 1909: sound 'tdm_ai_commander_there_you_are' previously defined at sound/tdm_ai_commander.sndshd:1407
7 warnings
pid: 1970
5040 MB System Memory
guessing video ram ( use +set sys_videoRam to force ) ..
found XNVCtrl extension 1.28
256 MB Video Memory
Async thread started
Couldn't exec autocommands.cfg - file does not exist.
]image_mipmapmode
"image_mipmapMode" is:"0" default:"2"
Mipmap generation mode: 0 - software, 1 - GL 1.4, 2 - GL 3.0
]image_mipmapmode 0
]condump unwrap mipmap.txt
Dumped console text to mipmap.txt.
For the record, this test was done on the following system (same hardware documented in detail in my post in the beta forum):
  • OS: clean, 32-bit Slackware 14.2 Linux, with OpenAL-Soft 1.17.2 library added
  • RAM: 5 GB
  • Video Driver: 32-bit nVidia 304.132
  • Video Card #1: nVidia 'GeForce 7600GT', 256MB video RAM, primary, connected to 2 1600x1200 monitors
  • Video Card #2: nVidia 'GeForce GT 640', 2GB video RAM, secondary, also connected to 2 1600x1200 monitors
  • CPU: (dual-core) 'AMD 6000+ Athlon 64 X2'
If you have other things you'd like me to try, please just let me know.

 

I also have this error when compiling trunk under 32-bit ubuntu:

In file included from game/script/Script_Doc_Export.cpp:26:0:
game/script/../pugixml/pugixml.hpp:1070:2: error: reference to basic_string is ambiguous
  std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > PUGIXML_FUNCTION as_wide(const char* str);
  ^~~
In file included from game/script/Script_Doc_Export.cpp:26:0:

 

Your error is the same as Crinkelite's. ATM, I have nothing to suggest to you or Crinkelite about that error because I never see it. And I'm not a big C++ guy either. Sorry.

 

Nevertheless, please be more specific when reporting these things. What version of Ubuntu and (probably more importantly) what version of GCC are you using?

Link to comment
Share on other sites

NightStalker,

It's ubuntu 16.10 32-bit, default gcc that comes with it.

My web searches resulted in this

http://stackoverflow.com/questions/34571583/understanding-gcc-5s-glibcxx-use-cxx11-abi-or-the-new-abi

I had no time to test this just yet

 

One thing I should probably mention is that Compilation guide did not exactly work for me.

sudo apt-get install g++ scons libglew1.5-dev libpng12-dev libjpeg62-dev

threw errors beyond my understanding so I dropped 1.5 and 12 and 62.

Link to comment
Share on other sites

It's ubuntu 16.10 32-bit, default gcc that comes with it.

Yes, but I have no idea what version of GCC comes with Ubuntu 16.10. Can you please run 'gcc --version' and report that (both now and anytime you switch to another Linux distro for compiling)?

Thanks for the URL. It looks like it will be useful at some point.

 

Having said that, and given the extra info from grayman (in that other Linux thread) about the SVN revisions used to make 2.05-beta, I'm currently more interested in trying to build (and run!) that oldest revision and working forward, so I may be distracted (and further unable to provide useful advice) from this particular build issue that you and Crinkelite are experiencing. My primary interest, in support of helping to get 2.05 "out the door", will be to get something to build and run, now that I know that grayman cannot run TDM on his Linux Virtual Machine (VM) setup.

One thing I should probably mention is that Compilation guide did not exactly work for me.

sudo apt-get install g++ scons libglew1.5-dev libpng12-dev libjpeg62-dev

threw errors beyond my understanding so I dropped 1.5 and 12 and 62.

If that info came from the wiki, it's probably somewhat outdated. And us Slackware guys don't often use "packages" -- we build from source, like real Linux men! ;) I don't think anyone's been updating the Linux parts of the wiki much. (That's another thing that could use some attention, but let's tackle one thing at a time. :laugh:)

Link to comment
Share on other sites

So where is it?

 

Sorry about the delay but as I indicated earlier, I'm getting the same compilation errors on ubuntu-32 as with archlinux-64

 

I've actually spent most of the interim wrestling with qemu and installing slackware.

It's not something I'm used to.

I'll post my results if I can manage to get slackware ready for compiling but I hope nobody's holding their breath :/

 

I'm delighted to see some positive action on the Linux build.

 

Ubuntu version 4.8.0-30 generic i686

gcc 6.2.0

ubuntu32-tdm_2.04.compiler-output.txt

Edited by Crinkelite
Link to comment
Share on other sites

Sorry about the delay but as I indicated earlier, I'm getting the same compilation errors on ubuntu-32 as with archlinux-64

Ubuntu version 4.8.0-30 generic i686

gcc 6.2.0

Thanks, Crinkelite! I took a quick look at your output. It really is the same kinds of errors as before, from what I've seen. I suspect it's due to the newer GCC that you (and, presumably, duzenko) are using, compared to my Slackware 14.2's GCC 5.3.0.

 

I suspect some combination of the 3 of us will get to the bottom of this eventually, but for the moment, I'm focused on the 2.05-beta source and not on 'latest SVN'. But as long as we're both patient with each other, we should be fine. :)

  • Like 1
Link to comment
Share on other sites

Yes, but I have no idea what version of GCC comes with Ubuntu 16.10. Can you please run 'gcc --version' and report that (both now and anytime you switch to another Linux distro for compiling)?

Thanks for the URL. It looks like it will be useful at some point.

gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005

 

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...