Jump to content


Photo

Compiling TDM 2.04 Under Linux

linux

  • Please log in to reply
68 replies to this topic

#51 NightStalker

NightStalker

    Linux hero

  • Development Role
  • PipPip
  • 159 posts

Posted 22 December 2016 - 09:40 PM

Crinkelite: If you have not already done so:

duzenko: When you return:

 

I would encourage you both to take a look at Hamlet's patches, specifically the 'pugi_strings.patch.txt' patch.  I think it will further your compilation attempts under Ubuntu 16.10.

 

I would be interested to hear your results if you get a chance to try it.



#52 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 911 posts

Posted 23 December 2016 - 03:26 AM

Will do, ETA 27.12.16.



#53 Hamlet

Hamlet

    Member

  • Member
  • PipPip
  • 25 posts

Posted 25 December 2016 - 11:29 PM

If may be of help...

 

I felt my virility diminished by the fact that Ubuntu uses GCC 6.2 and I do not, so I installed the latter and now my psychic balance is restored.

Compilation by GCC 6.2.0 of The Dark Mod with a set of patches that worked with GCC 5.4 went fairly well, except for one point. After all, you cant reasonably expect to get away with redefine'ing private into public.

I am attaching a patch (Attached File  gcc6-TypeInfo.patch.txt   1.59KB   5 downloads) that addresses the specific problem I encountered by including the "problematic" header before that redefinition happens. If other libraries (on any compiler) trigger the same problem in TypeInfo.cpp, the same approach can be used.


Edited by Hamlet, 25 December 2016 - 11:31 PM.

  • duzenko, nbohr1more and NightStalker like this

#54 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 911 posts

Posted 27 December 2016 - 10:02 AM

Crinkelite: If you have not already done so:

duzenko: When you return:

 

I would encourage you both to take a look at Hamlet's patches, specifically the 'pugi_strings.patch.txt' patch.  I think it will further your compilation attempts under Ubuntu 16.10.

 

I would be interested to hear your results if you get a chance to try it.

Pugxml has stopped complaining with that patch. It's good to be applied to trunk IMHO.

Now I have this access redeclaration error. AFAIR it was mentioned somewhere already but can't remember where and whether it has been sorted out.

P.S. Great job so far, Hamlet, NightStalker :)

Attached Files


  • NightStalker likes this

#55 NightStalker

NightStalker

    Linux hero

  • Development Role
  • PipPip
  • 159 posts

Posted 27 December 2016 - 11:37 AM

Pugxml has stopped complaining with that patch. It's good to be applied to trunk IMHO.

Please give me a bit of time to add the patch and test with it before anyone checks it into SVN. Even though I don't really need the patch, I'd like to test with it in place to ensure that nothing bad happens. (Not that I'm expecting that, I just want to be thorough).
 
I'm deep into debugging the Linux crashes that Baal was seeing, so it might take me another day or two to test the 'pugxml' patch.  After that, I will report back and then either you or I should probably check it into SVN.

Now I have this access redeclaration error. AFAIR it was mentioned somewhere already but can't remember where and whether it has been sorted out.

Actually, I believe that Hamlet's patch in the post immediately above yours will help. I've seen it, but not yet applied it, because, like the one mentioned above, Slackware 14.2 (GCC 5.3.0) doesn't need it to compile TDM. But I will also apply that one and test, in due time.


  • duzenko likes this

#56 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 911 posts

Posted 28 December 2016 - 05:21 AM

Actually, I believe that Hamlet's patch in the post immediately above yours will help.

Oops, that hurt :).

It kinda compiles for me now :awesome:. Didn't test how it runs because I'm on a VM and you guys run it on real hardware.

Here's my svn patch that combines the changes from multiple Hamlet's patches.

I think we're at the point where it should be applied to trunk.

Spoiler


#57 damiel

damiel

    Member

  • Member
  • PipPip
  • 14 posts

Posted 28 December 2016 - 09:56 AM

I am build trunk right now with your combined patch applied as i dont have access to 2.05 yet. Ill keep you updated how it runs once i am done building.

 

EDIT

 

Okay i get following error while building tdm:

 

 

scons: *** [build/debug/game/sys/scons/libgame.so] Implicit dependency `/usr/lib32/libboost_filesystem.so' not found, needed by target `build/debug/game/sys/scons/libgame.so'.
scons: building terminated because of errors.

 

I obviously dont have that directory, just /usr/lib/ and /usr/lib64. I have the missing libboost_filesystem.so which is a symlink to the versioned file of my distribution in /usr/lib64. Boost is installed as 32bit and 64bit package.


Edited by damiel, 28 December 2016 - 10:22 AM.


#58 NightStalker

NightStalker

    Linux hero

  • Development Role
  • PipPip
  • 159 posts

Posted 28 December 2016 - 11:40 AM

Here's my svn patch that combines the changes from multiple Hamlet's patches. I think we're at the point where it should be applied to trunk.

Very glad to hear of your compilation progress!

As for checking things into SVN, I really must beg a bit more patience, folks. Maybe I'm missing some relevant discussion on the "developers'" sub-forum (assuming there is one), but I really want to check these patches out a bit more and I think I like one of my patches better than (EDIT: part of) the one you're about to commit to SVN. But time is lacking ATM because I'm very deeply into the Baal crashes and this is not a simple issue (trust me!).

I really don't want us to be checking something into SVN only to have to adjust again later. All that does it is create SVN "churn", which makes a hard job (figuring out what's going on, especially for newcomers like myself with no project history) even harder. So, please, just a bit more patience. Today is going to be a very busy day for me, but I still hope to find more time to work the "Baal crash" issue. If that goes well then tomorrow I'd like to apply some of these patches and test.

I obviously dont have that directory, just /usr/lib/ and /usr/lib64. I have the missing libboost_filesystem.so which is a symlink to the versioned file of my distribution in /usr/lib64. Boost is installed as 32bit and 64bit package.

I'm very glad to hear that Hamlet's patches are helping both of you -- I suspected that they would. As for the "/usr/lib32" issue you mention, I implore you to go back and carefully re-read Hamlet's excellent, detailed post. He specifically mentions "(note the "/usr/lib32/" path in two places)". What he's saying there is that you need to adjust his command according to your system. Do that properly and please let us know if that works.


Edited by NightStalker, 28 December 2016 - 12:22 PM.

  • duzenko, nbohr1more and Hamlet like this

#59 New Horizon

New Horizon

    Mod hero

  • Active Developer
  • PipPipPipPipPip
  • 13784 posts

Posted 28 December 2016 - 01:14 PM

Sounds good NightStalker.  You folks take your time and make sure everything is well sorted.


  • Bikerdude and NightStalker like this

#60 Hamlet

Hamlet

    Member

  • Member
  • PipPip
  • 25 posts

Posted 29 December 2016 - 01:11 AM

As for the "/usr/lib32" issue you mention, I implore you to go back and carefully re-read Hamlet's excellent, detailed post. He specifically mentions "(note the "/usr/lib32/" path in two places)". What he's saying there is that you need to adjust his command according to your system. Do that properly and please let us know if that works.


If this project is really considering to require the compiling users to provide Boost (32 bits) from their own system, then it's probably time for me to scratch my head and my search engine to find a good Boost installation macro for AutoConf.
The one you ship failed miserably on my system, and there might be some better ones. Also I suppose that Windows and OSX users already pick Boost from the system?

Anyway, let me know.

Note that the first word in my statement is a true if. This project may decide that it's too much to ask to the users, or that it's too much of a burden to suddenly have to cope with the less-than-stable Boost interface in the wild.
My personal opinion is that it's worth, but I might even be... wow, wrong!

 

Last word for NightStalker: we all have a real life, we all take our time. I don't think you'll be blamed for that, and I am sure you shouldn't be. Newcomers (that is me!) typically have a burst of enthusiasm... I am sure I'll calm down soon.

(also I am not going to commit anything, and thrice-especially not on trunk).



#61 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 911 posts

Posted 29 December 2016 - 03:19 AM

I think Windows build has the boost libs in TDM svn:

src\win32\lib


#62 damiel

damiel

    Member

  • Member
  • PipPip
  • 14 posts

Posted 29 December 2016 - 06:29 PM

I'm very glad to hear that Hamlet's patches are helping both of you -- I suspected that they would. As for the "/usr/lib32" issue you mention, I implore you to go back and carefully re-read Hamlet's excellent, detailed post. He specifically mentions "(note the "/usr/lib32/" path in two places)". What he's saying there is that you need to adjust his command according to your system. Do that properly and please let us know if that works.

 

Thank you for the hint, i missed that little detail, it's kinda getting hard to follow every discussion with so many being around now! :)

 

Using the combined patch and hardcoding the path to the system copy of boost, makes everything compile just fine. After that i encountered the invisible man problem but luckily that one was resolved by using the missing pak file. I started a couple of missions now and everything seems to be fine, no crashes or other oddities.

 

So for me at this point there are only two concerns left now:

 

1. patch review

 

2. handling of boost libs and possibly other improvements to the build process for linux.


Edited by damiel, 29 December 2016 - 06:29 PM.


#63 NightStalker

NightStalker

    Linux hero

  • Development Role
  • PipPip
  • 159 posts

Posted 29 December 2016 - 06:56 PM

If this project is really considering to require the compiling users to provide Boost (32 bits) from their own system, [...]

Personally, I'm all for TDM not including all these headers and libraries in the source code distribution and/or the libraries in the run-time distribution. If the Windows users want and/or need that, that's fine with me. But that's just not "the Linux way" and is a path of slowly increasing pain.

But there are just too many things wrong with TDM (IMHO) at the moment that deserve more attention, so that's where my time will be directed, initially. I'd like to help grayman get 2.05 settled and "out the door" before I assault him or anyone else with potentially controversial ideas. :)

But, Hamlet, I think we are of one mind on the Boost stuff. And, if I'm still sane later on, I eventually plan to gently "campaign" for some improvements in that area.

Using the combined patch and hardcoding the path to the system copy of boost, makes everything compile just fine.

Excellent! Very glad to hear that, damiel -- thanks for the report! I plan to test the various outstanding patches within the next couple of days so that (hopefully) we will all soon agree on their "SVN-worthiness". Then, in theory, we'll all be able to simply pull from "latest SVN" with no extra hassle.

And, as I said to Hamlet, above, I foresee Linux build improvements (both small, uncontroversial ones and, hopefully, some larger ones), but it will take some time.

I hope both you guys hang around. I really appreciate all your inputs!


  • Bikerdude likes this

#64 NightStalker

NightStalker

    Linux hero

  • Development Role
  • PipPip
  • 159 posts

Posted 31 December 2016 - 07:00 PM

As for checking things into SVN, I really must beg a bit more patience, folks. Maybe I'm missing some relevant discussion on the "developers'" sub-forum (assuming there is one), but I really want to check these patches out a bit more and I think I like one of my patches better than (EDIT: part of) the one you're about to commit to SVN. But time is lacking ATM because I'm very deeply into the Baal crashes and this is not a simple issue (trust me!).

I've finally taken the time (sorry for the excessive delay, all!) to carefully check all of the patches that I think we're all wanting in SVN HEAD.

I've successfully test-compiled (and run) the TDM build under both 32-bit Slackware 14.2 with GCC 5.3.0 (my current, preferred setup) and under 32-bit Slackware 13.1 with GCC 4.4.4 (which is the closest I can reasonably come to grayman's GCC 4.4.3 setup).

This is the patchset I used:

Spoiler

The first 2 files patched are essentially Hamlet's patches ('gcc6-TypeInfo.patch' & 'pugi_strings.patch'), as-is, with 1 minor comment spelling error fixed ("loose" -> "lose") in the 1st file's patch.

The 3rd file is the portion of Hamlet's 'RenderMatrix_in_Linux.patch' that grayman has not already committed to SVN HEAD.

The last 2 files are a patch I submitted back on Dec 10th for what is essentially the same issue that Hamlet addressed with his 'inline.patch'. This is the only case where I preferred my patch over Hamlet's, simply because I think mine follows the latest direction of the DevIL library's header files a bit more closely (and I've been using it since even before Dec 10th, so it's reasonably well tested under Linux, with 2 versions of GCC).

Feel free to question or even outright disagree with anything I've asserted above, though, folks. I may have missed something and would appreciate a gentle knock on the head if so! :)

I have no way to compile under Windows, though. So if anyone who has that capability could make sure that nothing breaks under Windows (compile-wise at least and, ideally, run-time-wise) that would be very much appreciated.

If there are no objections within the next 3 days, my plan is to commit all of those patches to SVN HEAD, so that regardless of which version of GCC one is using (4.4.3 [grayman], 4.4.4 [NightStalker, simulating grayman], 5.3.0 [NightStalker], 5.4.0 [Hamlet], 6.2.0 [Hamlet, duzenko, Crinkelite, damiel]), we should all be able to successfully compile SVN HEAD. :awesome:

When the time comes, I plan to commit the changes to these 5 files in 4 pieces, so that they are added and can be removed (if needed) atomically.

Thanks to all for being patient with me on this!


  • New Horizon likes this

#65 Hamlet

Hamlet

    Member

  • Member
  • PipPip
  • 25 posts

Posted 01 January 2017 - 12:28 AM

Why not to push it in a branch now?

That would give willing people the chance to test it easily without compromising trunk, and after it's proven that it compiles in the other supported platforms, you can merge it to trunk.



#66 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 911 posts

Posted 01 January 2017 - 06:11 AM

I have no way to compile under Windows, though. So if anyone who has that capability could make sure that nothing breaks under Windows (compile-wise at least and, ideally, run-time-wise) that would be very much appreciated.

Compiles to me in vs2013 with your patch.

TRUNK! TRUNK! TRUNK!



#67 NightStalker

NightStalker

    Linux hero

  • Development Role
  • PipPip
  • 159 posts

Posted 01 January 2017 - 11:47 AM

Why not to push it in a branch now?
That would give willing people the chance to test it easily without compromising trunk, and after it's proven that it compiles in the other supported platforms, you can merge it to trunk.

I don't disagree with your logic one bit. The only impediments are (1) I'm very rusty with SVN and would not be comfortable trying to create a branch with my newly-minted SVN write privileges lest I mess something up! and (2) I don't even know if I could create a branch that would be readable to the public. I thought the patchset I supplied would be easy enough for people to merge into their local trees, but maybe I'm missing something?

Compiles to me in vs2013 with your patch.
TRUNK! TRUNK! TRUNK!

:laugh: Excellent! Many thanks for doing that test. The only reason I'm seeming to "drag my heels" on this is that I like to give everyone time to test and/or comment and I don't expect that all the Linux-compiling people read the forum as regularly as I have lately. But if the way I'm approaching this is an impediment, and since I'm too scared to try to create a public branch just now, I could commit that patchset later today if you guys think that's better.



#68 damiel

damiel

    Member

  • Member
  • PipPip
  • 14 posts

Posted 02 January 2017 - 03:44 PM

@NightStalker

 

i did gave your patch a run now, it compiles fine and the game is running without any noticable errors, so consider 64bit linux as tested. :)


  • nbohr1more likes this

#69 NightStalker

NightStalker

    Linux hero

  • Development Role
  • PipPip
  • 159 posts

Posted 02 January 2017 - 06:52 PM

i did gave your patch a run now, it compiles fine and the game is running without any noticable errors, so consider 64bit linux as tested. :)

Excellent...  many thanks for testing this, damiel!
 
@all: I'm getting quite mixed up as to where things have been discussed and I posted about committing all those patches to SVN in a different thread. Apologies for the confusion. Suffice it to say that I think we can all compile from SVN trunk now.







Also tagged with one or more of these keywords: linux

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users