Jump to content


Photo

Compiling TDM 2.04 Under Linux

linux

  • Please log in to reply
68 replies to this topic

#26 nbohr1more

nbohr1more

    Darkmod PR, Wordsmith

  • Development Role
  • PipPipPipPipPip
  • 7353 posts

Posted 11 December 2016 - 06:30 PM

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/r...od-Experimental


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

http://www.indiedb.c...ds/the-dark-mod

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

#27 grayman

grayman

    Master Builder, Coder

  • Active Developer
  • PipPipPipPipPip
  • 11538 posts

Posted 11 December 2016 - 06:41 PM

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.



#28 NightStalker

NightStalker

    Linux hero

  • Development Role
  • PipPip
  • 146 posts

Posted 12 December 2016 - 02:18 AM

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!



#29 duzenko

duzenko

    Member

  • Mission Beta Tester
  • PipPip
  • 217 posts

Posted 12 December 2016 - 02:52 AM

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?

#30 Crinkelite

Crinkelite

    Member

  • Mission Beta Tester
  • PipPip
  • 22 posts

Posted 12 December 2016 - 09:37 AM

 

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

Attached Files



#31 nbohr1more

nbohr1more

    Darkmod PR, Wordsmith

  • Development Role
  • PipPipPipPipPip
  • 7353 posts

Posted 12 December 2016 - 09:40 AM

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.


  • Crinkelite likes this
Please visit TDM's IndieDB site and help promote the mod:

http://www.indiedb.c...ds/the-dark-mod

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

#32 Baal

Baal

    Hero Mapper

  • Campaign Dev
  • PipPipPip
  • 989 posts

Posted 12 December 2016 - 11:00 AM

Nope, I just found out Manjaro has the same problem. It was the two missions that come with the mod that work. Everything else crashes on Manjaro, too.



#33 NightStalker

NightStalker

    Linux hero

  • Development Role
  • PipPip
  • 146 posts

Posted 12 December 2016 - 08:14 PM

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.



#34 NightStalker

NightStalker

    Linux hero

  • Development Role
  • PipPip
  • 146 posts

Posted 12 December 2016 - 08:19 PM

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!

#35 grayman

grayman

    Master Builder, Coder

  • Active Developer
  • PipPipPipPipPip
  • 11538 posts

Posted 13 December 2016 - 02:56 PM

Where do I find the patch that fixes the Linux problem of recompiling everything all the time?



#36 NightStalker

NightStalker

    Linux hero

  • Development Role
  • PipPip
  • 146 posts

Posted 13 December 2016 - 05:34 PM

Where do I find the patch that fixes the Linux problem of recompiling everything all the time?

Scroll back to post #28. Friendly reminder and link is there. ;)



#37 NightStalker

NightStalker

    Linux hero

  • Development Role
  • PipPip
  • 146 posts

Posted 13 December 2016 - 09:43 PM

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


  • Crinkelite likes this

#38 Baal

Baal

    Hero Mapper

  • Campaign Dev
  • PipPipPip
  • 989 posts

Posted 14 December 2016 - 09:24 AM

Where can I find the 2.05 sources? I checked out trunk from https://svn.thedarkm...rkmod_src/trunk but there is no 2.05 tag or branch. 

Trying to build that on Archlinux throws tons of errors.



#39 grayman

grayman

    Master Builder, Coder

  • Active Developer
  • PipPipPipPipPip
  • 11538 posts

Posted 14 December 2016 - 10:06 AM

https://svn.thedarkm...hes/release2.05

 

Do NOT commit anything to that branch.



#40 Baal

Baal

    Hero Mapper

  • Campaign Dev
  • PipPipPip
  • 989 posts

Posted 14 December 2016 - 12:22 PM

Thanks, understood.

 

Edit: I don't have access to this. Taaaki hasn't read me PM yet.


Edited by Baal, 14 December 2016 - 12:27 PM.


#41 Crinkelite

Crinkelite

    Member

  • Mission Beta Tester
  • PipPip
  • 22 posts

Posted 15 December 2016 - 10:18 AM

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. 



#42 NightStalker

NightStalker

    Linux hero

  • Development Role
  • PipPip
  • 146 posts

Posted 18 December 2016 - 12:04 PM

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.



#43 duzenko

duzenko

    Member

  • Mission Beta Tester
  • PipPip
  • 217 posts

Posted 19 December 2016 - 09:03 AM

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:


#44 NightStalker

NightStalker

    Linux hero

  • Development Role
  • PipPip
  • 146 posts

Posted 19 December 2016 - 01:58 PM

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?

#45 duzenko

duzenko

    Member

  • Mission Beta Tester
  • PipPip
  • 217 posts

Posted 19 December 2016 - 03:12 PM

NightStalker,

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

My web searches resulted in this

http://stackoverflow...-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.



#46 NightStalker

NightStalker

    Linux hero

  • Development Role
  • PipPip
  • 146 posts

Posted 19 December 2016 - 06:54 PM

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)?

My web searches resulted in this
http://stackoverflow...-or-the-new-abi
I had no time to test this just yet

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



#47 Bikerdude

Bikerdude

    Mod hero

  • Active Developer
  • PipPipPipPipPip
  • 17971 posts

Posted 19 December 2016 - 06:57 PM

Regarding Linux, at some I want to get my laptop to dual boot with Win7/Mint. So I can then be using a linux nube to test TDM under that OS etc.



#48 Crinkelite

Crinkelite

    Member

  • Mission Beta Tester
  • PipPip
  • 22 posts

Posted 19 December 2016 - 08:49 PM

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

Attached Files


Edited by Crinkelite, 19 December 2016 - 08:53 PM.


#49 NightStalker

NightStalker

    Linux hero

  • Development Role
  • PipPip
  • 146 posts

Posted 19 December 2016 - 09:44 PM

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


  • Crinkelite likes this

#50 duzenko

duzenko

    Member

  • Mission Beta Tester
  • PipPip
  • 217 posts

Posted 20 December 2016 - 05:55 AM

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

 







Also tagged with one or more of these keywords: linux

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users