EDIT: Meant to post this in the forum for install stuff, went one too high, sorry

I've been trying to get this game running for a few days now and I'm having a lot of trouble. I've managed to make varying amounts of progress trying to do it in different ways (e.g. with the normal source download, git master source and git development source using cmake, codeblocks, or given scripts) but I always seem to run into a series of increasingly weird problems and eventually stop because there's just no way I'm doing this right.

You can skip the below bit and jump right to the immediate problem if you wish - below is just a lead up to how I got where I am now.--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------I'm going to start with the normal source download (the 0.4.9 Linux source from the download page here http://sourceforge.net/projects/opendun ... 20Release/).

So, first I run into this:

CMake Error: The current CMakeCache.txt directory /home/dylan/GameAndInstallStuff/Games/opendungeons/CMakeCache.txt is different than the directory /home/tom/Opendungeons/opendungeons where CMakeCache.txt was created. This may result in binaries being created in the wrong place. If you are not sure, reedit the CMakeCache.txt

Well, okay, a little weird but simple enough. But replacing all the "/home/tom/Opendungeons/opendungeons" paths with the appropriate one results in this:

Note: there is no AbstractApplicationMode.cpp anywhere within the extracted directory. There *is*, however, a "/home/dylan/GameAndInstallStuff/Games/opendungeons/CMakeFiles/OpenDungeons.bin.dir/source/" directory with an AbstractApplicationMode.cpp.o file. So, I skipped the whole cmake bit entirely since it's already been run and, though it's perhaps not ideal, I just changed the directory in all the configuration files I could find and ran make. That resulted in this:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------Current Problem

This file doesn't appear to exist anywhere within that directory (I'd note it *does* exist in the git ones, though the problems with those are also angelscript related). Not really sure where to go from here. So - has anyone been able to get this to compile successfully on Linux? I noticed there weren't really a ton of downloads for that version.

Heh seems my push of my Opendungeons directory tree causes more confusion than good.The whole thing is intended to start ./Opendungeons.bin , that is to try launching the binary out of the package.Sure the CMAKE's caches are invalid cause they keep settings from my computer. Further steps depends hard on what you wanna to do with OD . If only play try Windows bundle. You could however try getting to run raw binary exec I included in this package. This would involve heavy debbuging and pasting your OS and librarires configuration . Use git repo to compile it on your machine , not my tar gz package ( seems I should remove it anyway)

No idea why this one gives c++11 errors. I can work around those in codeblocks, but then I get a whole bunch of weird errors with more popping up as I fix them, mostly having to do with missing files. Currently I'm up to

Note that I'd already added several files from the master branch because they weren't found at this point. I gave up here because I'm clearly setting it up wrong if I have to keep going to fetch other code files that weren't in the repository.

/usr/include/c++/4.8.2/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.

Sorry FAQ states clearly how to set that .

Each compiler has it's C++0x or C++11 flag, for GNU g++ it's :"g++ --std=c++11"On CMake, make sure to add that to the CMakeCxxFlags.Or type bash cmd 'cmake-gui' it opens graphical configurator, unfold the CMake node. And find the CMakeCxxFlags flag.

Hi there, I'm also trying to build OD on Linux, and I run into another issue when building AngelScript.

I didn't know anything about C++11, but I read what was posted here and tried to specify CMAKE_CXX_FLAGS="-std=c++11", but it did not solve the issue. Note that I have no mention of making use of the wrong compiler as Dylan got.

Here is what I get when running cmake (note that I tweaked the FindCEGUI.cmake file so that it finds CEGUI 0.8.3, upstream like to change their paths and sonames every other release it seems):

I actually just got the dev version to compile...ish...by setting std=c++11. Turns out that it wasn't taking when I set it through the GUI for some reason, so I set it in the text file manually and it worked. Now I'm just having some SFML issues, trying to figure out why. If you're using the master version, try the dev one instead.

Dylan {l Wrote}:I actually just got the dev version to compile...ish...by setting std=c++11. Turns out that it wasn't taking when I set it through the GUI for some reason, so I set it in the text file manually and it worked. Now I'm just having some SFML issues, trying to figure out why. If you're using the master version, try the dev one instead.

Could you tell me what you added precisely so that it works? I've tried with cmake-gui and with manual tweaks in CMakeLists.txt, but I haven't seen a difference yet.

For the dev version I had to go into the CMakeCache.txt file itself and change the "CMAKE_CXX_FLAGS:STRING=" section to "CMAKE_CXX_FLAGS:STRING=-std=c++11". For some reason it doesn't show up in the UI and trying to add it has no effect for me. This *only* worked for the dev version though, no difference in the master branch that I saw.

As you both have rightly observed, the current cmakefile is not working well. There are a few problems which we will try to address more clearly soon. It also doesn't help that the development branch requires newer and libraries, incompatible with the old one. Also, after it is compiled, you also need to copy the media files into a media/ directory so opendungeons can find it (also being addressed).

Given the library incompatibilties and slightly better situation in development, I would recommend you check out the development branch. This is also the branch I know best and will describe.

CMake Error: The current CMakeCache.txt directory /home/dylan/GameAndInstallStuff/Games/opendungeons/CMakeCache.txt is different than the directory /home/tom/Opendungeons/opendungeons where CMakeCache.txt was created. This may result in binaries being created in the wrong place. If you are not sure, reedit the CMakeCache.txt

I would guess you would have ran cmake; copied it from one user to another, then checked out the source, and tried to run cmake again. Unfortunately, cmake does not like that. Rather then editing the cmakecache.txt file, the right course of action would be to delete it instead and try it again.

Note: there is no AbstractApplicationMode.cpp anywhere within the extracted directory. There *is*, however, a "/home/dylan/GameAndInstallStuff/Games/opendungeons/CMakeFiles/OpenDungeons.bin.dir/source/" directory with an AbstractApplicationMode.cpp.o file

To my best guesses, this file is available in devel and not in master; this also hints that you switched branched and ran cmake again; this .o file would be a leftover from the development compilation environment. (as would be the cmakecache, which now tries to make you compile devel in the master tree, more or less). The 'current problem in this post would also indicate the same. I advice to delete the cmakecache file, or better, clean the whole git directory so you are sure no traces of the old environment are left.

OpenDungeons requires c++11 in order to get compiler. Development has a check for gcc and sets -std=c++11 if it is the compiler used.

Hi there, I'm also trying to build OD on Linux, and I run into another issue when building AngelScript.

Could you check the code? I see that function on line 391. looking around for this problem it seemed it might have to do with a hidden dependency on irricht which angelscript doesn't mention. If you aren't using it, I would also like to recommend you to check out the development branch and clean the tree before compiling.

I'm not sure it's convenient to edit CMakeCache.txt manually so I recommend you to do something like this in

A similar check already exists for gcc. Also I would recommend against using variables as such the USE_CPP2011 you propose if they are to be set in a fixed position, as opposed to beging configurable.

I hope this will help you get on your way. Should it fail, I would like to request you provide your cmakecache.txt file which can give more insight in the differnet configuration options that are present. Good luck in getting it compiled and I would love to hear your progress.

Could you check the code? I see that function on line 391. looking around for this problem it seemed it might have to do with a hidden dependency on irricht which angelscript doesn't mention. If you aren't using it, I would also like to recommend you to check out the development branch and clean the tree before compiling.

Many thanks nido! Paul and you said it quite a few time already, and I was really convinced I was running the development branch, but it was actually master. I'm not that experienced with git yet, but I'm learning :-)

So, switching to the dev branch, I'm having the same issues as Dylan. As he did, I could circumvent the failed setting of the CMAKE_CXX_FLAGS by editing the CMakeCache.txt.For the record, running "cmake -DCMAKE_CXX_FLAGS=-std=c++11 .." does the trick too.

Now I'm running into a CEGUI include issue, but that's just because I packaged CEGUI 0.8.3 for Mageia using upstream's default paths, and they really like to break everything (now the includes are in /usr/include/cegui-0/CEGUI for example, and every CEGUI lib is suffixed with -0...)Edit: I fixed this with this argument for CMake: -DCEGUI_INCLUDE_DIR=/usr/include/cegui-0 and that's exactly what it's meant for

For the reference, here is the patch I'm using to have CMake find my CEGUI 0.8.3 and SFML2 libraries:

It seems OD makes use of OGRE's Plugin_CgProgramManager.so.1.9.0, but in Mageia we don't build this plugin for OGRE. Cg is proprietary software and deprecated, so we even dropped it from the distro. Even if we still had Cg and wanted to build OGRE against cg-devel, we would need to put the whole OGRE package in our nonfree repository, since the core (free software) repository can't require nonfree dependencies.

Naah our Cmake scripts are far from being complete and reliable . I had to debug just now our script with

make VERBOSE=1

just to link the sfml system and audio libs. ( set the correct g++ -l linker flag) . Don't know how the escape from CG recipe work .... in prev. Ogre version I was able to do that ... don't see how it works for 1.9 though ... you must find yourself and tell us , so we add that to FAQ .

paul424 {l Wrote}:Don't know how the escape from CG recipe work .... in prev. Ogre version I was able to do that ... don't see how it works for 1.9 though ... you must find yourself and tell us , so we add that to FAQ .

Commenting out "Plugin=Plugin_CgProgramManager" in plugins.cfg does the trick Since it is a proprietary dependency, maybe it would be wise to have it disabled as the default behaviour? It could maybe switch on/off on build time using a CMake variable (OGRE_WITH_CG or such)?

Akien {l Wrote}:Edit: I fixed this with this argument for CMake: -DCEGUI_INCLUDE_DIR=/usr/include/cegui-0 and that's exactly what it's meant for

yay~. Also thank you for giving me an extra excuse to include that path as a custom default path for searching the library.

<code>

Would you mind it if I use parts of this code in my efforts to rebuild the cmakefile? If I am not mistaken, the file you edited is one which is copied from upstream. I could check it out and get back to you about it so you can also report it there if you like.

The diff looks like it removes the content to add it back, so I suppose it's some kind of end-of-line issue. It's no big deal but somewhat annoying when I want to produce a git diff :-)

I experience the same problem. This would be fixed once the dependencies have been put into their own external archive, which is a progress we are working on.

Akien {l Wrote}:Edit: I fixed this with this argument for CMake: -DCEGUI_INCLUDE_DIR=/usr/include/cegui-0 and that's exactly what it's meant for

yay~. Also thank you for giving me an extra excuse to include that path as a custom default path for searching the library.

Yes from what I've understood CEGUI decided to change its SONAME and include path once again when changing to 0.8.x. I don't know CEGUI much, but we had 0.7.9 packaged in Mageia, so I took some time to find out how to build 0.8.3 (they moved to cmake and changed quite a few things). I didn't submit my changes to Mageia yet, though, because we only have Super Maryo Chronicles that depends on CEGUI, and it won't build with CEGUI 0.8.x. Hopefully smc's upstream resurrects and ports it before I decide to package OD :-D

nido {l Wrote}:

<code>

Would you mind it if I use parts of this code in my efforts to rebuild the cmakefile? If I am not mistaken, the file you edited is one which is copied from upstream. I could check it out and get back to you about it so you can also report it there if you like.

If you mean my patch to the .cmake files, go on :-) For cegui-0 the new path is the default upstream path, so the fix might be wise.

For SFML2 I would double check though. Looking at Mageia's SFML2 package spec file, it seems we decided to put it there and add the %{version} tag to the libname:

So basically my change to the FindSFML.cmake file is a dirty fix, and it would be better to use pkgconfig to locate SFML2, so that every distro can put it wherever they want if they edit the pkgconfig files accordingly.

Akien {l Wrote}:So, switching to the dev branch, I'm having the same issues as Dylan. As he did, I could circumvent the failed setting of the CMAKE_CXX_FLAGS by editing the CMakeCache.txt.For the record, running "cmake -DCMAKE_CXX_FLAGS=-std=c++11 .." does the trick too.

To make the CMAKE_CXX_FLAGS correctly set, on Debian, I had to put the project() statement before the part where that variable is set.Unfortunately, doing this is breaking some other people cmake invocation, eg: Paul's.