Jump to content
The Dark Mod Forums

Compiling Dark Radiant on Mageia (Cauldron), new boost_filesystem errors...


PranQster

Recommended Posts

./configure ran fine (though I had to install extra, unlisted packages before it said there was python scripting support*).

Then I got this during make:

 

In file included from main.cpp:13:0:

log/PIDFile.h: In constructor 'applog::PIDFile::PIDFile(const std::string&)':

log/PIDFile.h:42:31: error: 'class boost::filesystem3::path' has no member named 'file_string'

make[2]: *** [darkradiant-main.o] Error 1

 

Any idea what I can do to fix that?

 

 

*The extra packages (not listed in the wiki) I installed in order for python scripting to report as available were as follows:

lib64gtksourceviewmm-2.0-devel

python-gtksourceview-devel

lib64gtkmm2.4-static-devel

Edited by PranQster

System: Mageia Linux Cauldron, aka Mageia 8

Link to comment
Share on other sites

Fixed that error.

 

I had to open /radiant/log/PIDFile.h and change line 42 from:

std::string logPath = path.file_string();

to:

std::string logPath = path.string();

 

Turns out that file_string had been deprecated.

 

Grrrr! Now I get this later on:

 

selection/algorithm/Primitives.cpp: In function ‘void selection::algorithm::createCMFromSelection(const cmd::ArgumentList&)’:

selection/algorithm/Primitives.cpp:314:48: error: invalid conversion from ‘bool (*)(const std::string&)’ to ‘boost::enable_if_c<true, void>::type*’

selection/algorithm/Primitives.cpp:314:48: error: initializing argument 2 of ‘boost::filesystem3::path::path(const Source&, typename boost::enable_if<boost::filesystem3::path_traits::is_pathable<typename boost::decay<Source>::type> >::type*) [with Source = std::basic_string<char>, typename boost::enable_if<boost::filesystem3::path_traits::is_pathable<typename boost::decay<Source>::type> >::type = void]’

make[2]: *** [darkradiant-Primitives.o] Error 1

 

LOL, oh the joys of poking around in source files.

System: Mageia Linux Cauldron, aka Mageia 8

Link to comment
Share on other sites

I had the same problem compiling the mod on arch linux, wich comes with a current version of boost. I got it to compile with some changes but they result in errors at runtime.

To compile the mod with a recent version of boost you have to look closer at boost_filesystems documentation (some things were deprecated) and adjust the mod code.

 

Edit: You're talking about the editor not the mod. I got that confused.

Link to comment
Share on other sites

Fixed that error.

 

I had to open /radiant/log/PIDFile.h and change line 42 from:

std::string logPath = path.file_string();

to:

std::string logPath = path.string();

 

Turns out that file_string had been deprecated.

 

Hm, I see if I can make that change and it still works with older boost. If so, I gladly patch the source so v1.07 will be all right for you. If you have more changes, please send them in!

 

We as developers do not have the resources to compile the mod on different linux versions, as there are only actual two people (me stuck on an older system, and greebo doing the release compilation on a more modern system), and we cannot catch all problems. Sorry.

 

(And btw, I was never a fan of adding these boost libraries to TDM, as they have often caused a few problems in the past, and in quite a few cases it seems they caused more problems than they actually solved. IMO it would have been better to add the nec. functions to the idlib instead, which does 95% of what we need, anyway, and most of all, works with the different compilers. But such things are not my decision.).

 

Edit: It seems you talk about DarkRadiant, not the main TDM source? Sorry, then I can't even apply the patch, you need to PM greebo or Orbweaver for this.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

If you have more changes, please send them in!

I have adjusted and compiled the editor with the most recent boost version and I could try to do the same with the mod. But I don't know how that would work with other distributions.

Link to comment
Share on other sites

Ah yes, sorry guys, I failed to mention that this is for DR, not TDM.

 

Fixed the second error!

After some googling, I found a post from someone else getting the same error when compiling a different program. Their solutio is to add this at the beginning of the .cpp file which throws the error:

#define BOOST_FILESYSTEM_VERSION 2

 

I did that to selection/algorithm/Primitives.cpp and make continued, then I had to do it again to the following:

map/AutoSaver.cpp

map/StartupMapLoader.cpp

make is still building now. Will add more .cpp files to this list as they occur.

I also had to steal libgdkmm-2.4.la from a debian .deb package, because my distro was missing this. Also, libgiomm-2.4.la & libpangomm-1.4.la as well.

Edited by PranQster

System: Mageia Linux Cauldron, aka Mageia 8

Link to comment
Share on other sites

Next comes this:

 

In file included from RenderableParticleBunch.h:15:0,

from RenderableParticleStage.h:4,

from RenderableParticle.h:4,

from ParticleNode.h:8,

from ParticleNode.cpp:1:

ParticleRenderInfo.h: In constructor 'particles::ParticleRenderInfo::ParticleRenderInfo(size_t, boost::random::rand48&)':

ParticleRenderInfo.h:62:44: error: 'max_value' is not a member of 'boost::random::rand48'

 

I'll see if something similar to #define BOOST_FILESYSTEM_VERSION 2 will work in this case, in a .h rather than a .cpp.

 

 

Nope. That's where I'm stuck now :(

 

Doing a search for 'boost::rand48::max_value' doesn't come up with much, but google suggests 'boost::drand48::max_value', which finds several pages.

Adding the d to those lines only gave me a 'drand48 not defined' error.

Edited by PranQster

System: Mageia Linux Cauldron, aka Mageia 8

Link to comment
Share on other sites

Decided to grab the lib64boost*.rpm files from a Mandriva 2010.2 mirror, along with some lib64gtkmm & lib64glibmm & libpangomm & lib64cairomm & lib64sigc++2.0 packages.

Compilation is now going forward again. I hope it doesn't stop, complaining about lack of De language support, like I had happen the last time I compiled DR.*

 

* Installed localization for De language, though I don't know much German... might be the easiest way around DR complaining about it being missing.

Edited by PranQster

System: Mageia Linux Cauldron, aka Mageia 8

Link to comment
Share on other sites

ParticleRenderInfo.h:62:44: error: 'max_value' is not a member of 'boost::random::rand48'

A member function called "max()" is the replacement for "max_value in boost 1.47.

 

I can give you my source files if you want. But I think you're almost there. It weren't that many fixes necessary if I remember correctly.

Link to comment
Share on other sites

A member function called "max()" is the replacement for "max_value in boost 1.47.

 

I can give you my source files if you want. But I think you're almost there. It weren't that many fixes necessary if I remember correctly.

 

Awesome! Thanks. I'll try this later tonight.

I got the pre-built debian-n version to work, after doing all of the cross-distro package swapping. Ironically, I ended up installing Mageia Cauldron's packages again, then DR worked once I added lib64atkmm. blink.gif

System: Mageia Linux Cauldron, aka Mageia 8

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

    • OrbWeaver

      Has anyone had any luck with textures from Polyhaven? Their OpenEXR normal maps seem too washed out and give incorrect shading in the engine.
      · 3 replies
    • datiswous

      I tried to upscale the TDM logo video. First try:

      briefing_video.mp4 You can test it ingame by making a copy of the core tdm_gui.mtr and place it in your-tdm-root/materials/ , then edit line 249 of that file into the location where you placed the new briefing.mp4 file.
      What I did was I extracted all the image files, then used Upscayl to upscale the images using General photo (Real-Esrgan) upscale setting and then turn it back into a video.
      I might have to crop it a bit, the logo looks smaller on screen (or maybe it's actually better this way?). My video editor turned it into a 16:9 video, which I think overal looks better than 1:1 video of original.
      · 1 reply
    • nbohr1more

      Trying to be productive on my down-time before Capcom releases Akuma and my son is constantly on my PC playing Street Fighter...
      · 1 reply
    • OrbWeaver

      Finally got round to publishing a tutorial on baking normal maps in Blender, since most of the ones we have are inaccessible or years out of date.
      · 2 replies
    • nbohr1more

      The FAQ wiki is almost a proper FAQ now. Probably need to spin-off a bunch of the "remedies" for playing older TDM versions into their own article.
      · 1 reply
×
×
  • Create New...