[6912] on Arch Linux - ogre 1.9?

[Chriss]

I'm trying to compile FO on Arch Linux, the SVN Trunk - 6912. Arch has boost 1.55.0 and ogre 1.9.0.

I'm getting the following Error snippet (full log is attached):

Code: Select all

[ 81%] Building CXX object client/human/CMakeFiles/freeorion.dir/__/__/UI/CombatSetupWnd.cpp.o
In file included from /usr/include/OGRE/OgreMaterial.h:31:0,
                 from /home/chris/freeorion-workdir/freeorion-svn/freeorion/FreeOrion/UI/CombatWndFwd.h:5,
                 from /home/chris/freeorion-workdir/freeorion-svn/freeorion/FreeOrion/UI/CombatWnd.h:5,
                 from /home/chris/freeorion-workdir/freeorion-svn/freeorion/FreeOrion/UI/CombatSetupWnd.cpp:3:
/usr/include/OGRE/OgrePrerequisites.h:314:33: error: conflicting declaration 'typedef class Ogre::SharedPtr<Ogre::Material> Ogre::MaterialPtr'
     typedef SharedPtr<Material> MaterialPtr;
                                 ^
In file included from /home/chris/freeorion-workdir/freeorion-svn/freeorion/FreeOrion/UI/CombatSetupWnd.cpp:1:0:
/home/chris/freeorion-workdir/freeorion-svn/freeorion/FreeOrion/UI/CombatSetupWnd.h:14:11: error: 'class Ogre::MaterialPtr' has a previous declaration as 'class Ogre::MaterialPtr'
     class MaterialPtr;
           ^

The files were generated with:
cmake . 2>&1 | tee freeorion-arch-cmake.log
make -j1 -k 2>&1 | tee freeorion-arch-build.log

Is ogre 1.9.0 a problem? Is the cmake output enough for all the dependencies and versions? I had to make a symlink /usr/include/freetype to freetype2. Otherwise, it compiled nicely with make -j4 and my 4 gigs of RAM.

[Geoff the Medio]

Is ogre 1.9.0 a problem?

Yes, as noted here: viewtopic.php?f=24&t=8168&p=65160#p65160 (although your post actually gives the specific error...)

[Chriss]

Ah, thanks. I missed that one.

Just found out how to change the ogre finding logic - it compiles fine with 1.8.1.

For reference, It's aparently set-up in

Code: Select all

GG/cmake/FindOGRE.cmake

and on Arch there's an ogre-1.8 AUR Package which installs in /opt/, so:

Code: Select all

export OGRE_HOME=/opt/OGRE-1.8/

then run cmake again, and it compiles.

[adrian_broher]

I had to make a symlink /usr/include/freetype to freetype2

Don't do that. The FindFreetype module we currently use doesn't respect the new location of the freetype2 headers. I will update the scrip accordingy and maybe I finally can push my change to cmake.

Is ogre 1.9.0 a problem?

We probably shouldn't forward declare types that aren't under our control (see the Ogre namespace full of forward declarations in UI/CombatSetupWnd.h). I will fix that.

Chriss, would you be willing to test the changes if the hit the respository?

[Chriss]

Don't do that. The FindFreetype module we currently use doesn't respect the new location of the freetype2 headers. I will update the scrip accordingy and maybe I finally can push my change to cmake.

Well...
I know it may be dirty, but it's a quick fix and doesn't change a lot. Didn't know a better way, too. Took the hint and removed the symlink anyway...

We probably shouldn't forward declare types that aren't under our control (see the Ogre namespace full of forward declarations in UI/CombatSetupWnd.h). I will fix that.

Chriss, would you be willing to test the changes if the hit the respository?

Sure. I'll subscribe here so I should get an email. If you'll answer or get in touch any other way, I'll do an update and recompile. You can also send me patches, I should be able to apply them if you don't want to commit anything yet.

[adrian_broher]

With revision 6913 it should be possible to compile FreeOrion with Ogre 1.9.

[adrian_broher]

With revision 6913 the FindFreetype.cmake module should now find the changed header layout of freetype2 without symlink hacks.

[Chriss]

Revision 6917. No Freetype Link, Ogre 1.9.0 (package rev 4).

[ 80%] Building CXX object client/human/CMakeFiles/freeorion.dir/__/__/UI/CombatWnd.cpp.o
/home/chris/freeorion-workdir/freeorion-svn/freeorion/FreeOrion/UI/CombatWnd.cpp: In Elementfunktion »virtual void CombatWnd::StencilOpQueueListener::renderQueueStarted(Ogre::uint8, const String&, bool&)«:
/home/chris/freeorion-workdir/freeorion-svn/freeorion/FreeOrion/UI/CombatWnd.cpp:541:73: Fehler: keine passende Funktion für Aufruf von »Ogre::RenderSystem::setStencilBufferParams(Ogre::CompareFunction, const uint32&, unsigned int, Ogre::StencilOperation, Ogre::StencilOperation, Ogre::StencilOperation, bool)«
Ogre::SOP_KEEP, Ogre::SOP_KEEP, Ogre::SOP_REPLACE, false);
^
/home/chris/freeorion-workdir/freeorion-svn/freeorion/FreeOrion/UI/CombatWnd.cpp:541:73: Anmerkung: Kandidat ist:
In file included from /usr/include/OGRE/OgreSceneManager.h:57:0,
from /home/chris/freeorion-workdir/freeorion-svn/freeorion/FreeOrion/UI/CombatSetupWnd.h:10,
from /home/chris/freeorion-workdir/freeorion-svn/freeorion/FreeOrion/UI/CombatWnd.cpp:7:
/usr/include/OGRE/OgreRenderSystem.h:1169:16: Anmerkung: virtual void Ogre::RenderSystem::setStencilBufferParams(Ogre::CompareFunction, Ogre::uint32, Ogre::uint32, Ogre::uint32, Ogre::StencilOperation, Ogre::StencilOperation, Ogre::StencilOperation, bool)
virtual void setStencilBufferParams(CompareFunction func = CMPF_ALWAYS_PASS,
^
/usr/include/OGRE/OgreRenderSystem.h:1169:16: Anmerkung: keine bekannte Umwandlung für Argument 7 von »bool« nach »Ogre::StencilOperation«

Full log is attached. Ah, I'll rerun it with Lang=en.EN.utf-8...
Edit: File exchanced with one with englisch commentary. Though for you, that's probably not necessary...

That seems to be all, though...

[adrian_broher]

No Freetype Link.

Did you delete the CMakeCache.txt before testing this? CMake prefers settings and paths that have been already found so it doesn't reconfigure the build completely.

eine passende Funktion für Aufruf von »Ogre::RenderSystem::setStencilBufferParams

Ogre 1.9 added a parameter to this function, so I have added a compile conditional value for the write mask.

Could you please try if FO now compiles properly with most recent commit?

[Chriss]

Yes, it does compile. I did a make clean, removed the cache file, and created a build directory where I ran "cmake .." and make. Is that supported? Cause:

[chris@chris-u38n-arch build]$ pwd
/home/chris/freeorion-workdir/freeorion-svn/freeorion/FreeOrion/build
[chris@chris-u38n-arch build]$ ./freeorion
main() caught exception(std::runtime_error): Unable to load game resources at default location: /home/chris/freeorion-workdir/freeorion-svn/freeorion/FreeOrion/build/default : Install may be broken.
main() failed config.
[chris@chris-u38n-arch build]$ ln -s ../default/ default
[chris@chris-u38n-arch build]$ ./freeorion
main() caught exception(std::exception): OGRE EXCEPTION(7:InternalErrorException): Could not load dynamic library RenderSystem_GL. System Error: RenderSystem_GL.so.1.9.0: cannot open shared object file: No such file or directory in DynLib::load at /build/ogre/src/ogre/OgreMain/src/OgreDynLib.cpp (line 109)

I'll recompile it without the build dir and test again. Btw: Build took 30 Minutes on my 1.6 Ghz AMD A8-4555M APU with make -j2 and about 3.2 Gigs of usable memory. The SSD might help.

[adrian_broher]

Is that supported?

Out of source builds are somewhat supported. As you already found out the cmake build doesn't create a symlink to the data directory so you need to create it manually.

This however:

[chris@chris-u38n-arch build]$ ./freeorion
main() caught exception(std::exception): OGRE EXCEPTION(7:InternalErrorException): Could not load dynamic library RenderSystem_GL. System Error: RenderSystem_GL.so.1.9.0: cannot open shared object file: No such file or directory in DynLib::load at /build/ogre/src/ogre/OgreMain/src/OgreDynLib.cpp (line 109)

is a well known bug.

Orge tries to locate its plugins by reading the „Plugin_Dir“ variable from the ogre config file. This file is generated by cmake and for some reason cmake doesn't populate it properly when running it in a clean build directory.

I haven't found a solution for that yet and I didn't bother to find one for the developer builds. The current workaround 'cmake . && cmake . && make && sudo make install' works for me.

Btw: Build took 30 Minutes on my 1.6 Ghz AMD A8-4555M APU with make -j2 and about 3.2 Gigs of usable memory.

Are those numbers with or without ccache? Maybe one of the previous attempts had already something cached, I wouldn't expect a clean build this fast.

[Chriss]

Ah, you already answered... I'll leave this for reference for now, though It's probably obsolete...

Okay, so this

[chris@chris-u38n-arch FreeOrion]$ ./freeorion
main() caught exception(std::exception): OGRE EXCEPTION(7:InternalErrorException): Could not load dynamic library RenderSystem_GL. System Error: RenderSystem_GL.so.1.9.0: cannot open shared object file: No such file or directory in DynLib::load at /build/ogre/src/ogre/OgreMain/src/OgreDynLib.cpp (line 109)

Seems to be an ogre configuration issue, sinde those files are there:

[chris@chris-u38n-arch FreeOrion]$ ls /usr/lib/OGRE/
cmake Plugin_OctreeSceneManager.so.1.9.0 Plugin_PCZSceneManager.so.1.9.0
Plugin_BSPSceneManager.so Plugin_OctreeZone.so RenderSystem_GL.so
Plugin_BSPSceneManager.so.1.9.0 Plugin_OctreeZone.so.1.9.0 RenderSystem_GL.so.1.9.0
Plugin_CgProgramManager.so Plugin_ParticleFX.so Samples
Plugin_CgProgramManager.so.1.9.0 Plugin_ParticleFX.so.1.9.0
Plugin_OctreeSceneManager.so Plugin_PCZSceneManager.so
[chris@chris-u38n-arch FreeOrion]$ ls /usr/lib64/OGRE/
cmake Plugin_OctreeSceneManager.so.1.9.0 Plugin_PCZSceneManager.so.1.9.0
Plugin_BSPSceneManager.so Plugin_OctreeZone.so RenderSystem_GL.so
Plugin_BSPSceneManager.so.1.9.0 Plugin_OctreeZone.so.1.9.0 RenderSystem_GL.so.1.9.0
Plugin_CgProgramManager.so Plugin_ParticleFX.so Samples
Plugin_CgProgramManager.so.1.9.0 Plugin_ParticleFX.so.1.9.0
Plugin_OctreeSceneManager.so Plugin_PCZSceneManager.so

And according to a very helpful comment in a bug report with similar content this is an ogre configuration issue. I did find some sample configs

[chris@chris-u38n-arch FreeOrion]$ sudo find / -iname '*ogre.cfg*'
/usr/share/OGRE/Samples/Browser/WinRT.Xaml/ogre.cfg
/usr/share/OGRE/Samples/Browser/WinRT/OGRE.CFG

but I'm not sure what to do with them. I googled ogre.cfg and found some tutorial like thing that mentiones that this can also be done in code. Is this an issue of my ogre installation? Any pointers?

Btw: What do those changed draw calls with the additional argument draw? I'll have a look if it looks funny as soon as I get FO to run again.

[Chriss]

I haven't found a solution for that yet and I didn't bother to find one for the developer builds. The current workaround 'cmake . && cmake . && make && sudo make install' works for me.

I didn't run make install, but running cmake again seems to have fixed it. I got to the start screen.

Are those numbers with or without ccache? Maybe one of the previous attempts had already something cached, I wouldn't expect a clean build this fast.

I never installed nor configured ccache. There are no ccache binaries and the package is not installed. So I'm quite sure ccache is not at work. I do have an SSD in my Laptop (Samsung 840) - AFAIK SSDs help with compiles. Maybe more than I thought?

Btw: What do those changed draw calls with the additional argument draw? I'll have a look if it looks funny as soon as I get FO to run again.

Probably not the next 2 days, but I'll playtest again eventually.

[Chriss]

This however:

[chris@chris-u38n-arch build]$ ./freeorion
main() caught exception(std::exception): OGRE EXCEPTION(7:InternalErrorException): Could not load dynamic library RenderSystem_GL. System Error: RenderSystem_GL.so.1.9.0: cannot open shared object file: No such file or directory in DynLib::load at /build/ogre/src/ogre/OgreMain/src/OgreDynLib.cpp (line 109)

is a well known bug.

Orge tries to locate its plugins by reading the „Plugin_Dir“ variable from the ogre config file. This file is generated by cmake and for some reason cmake doesn't populate it properly when running it in a clean build directory.

I haven't found a solution for that yet and I didn't bother to find one for the developer builds. The current workaround 'cmake . && cmake . && make && sudo make install' works for me.

A buddy of mine said this should fix that:

Code: Select all

Index: CMakeLists.txt
===================================================================
--- CMakeLists.txt	(revision 6948)
+++ CMakeLists.txt	(working copy)
@@ -69,6 +69,7 @@
     message(FATAL_ERROR "Unknown platform type! Your setup is not a supported platform for FreeOrion.")
 endif ()
 
+find_package(OGRE)
 configure_file(
     ${CMAKE_SOURCE_DIR}/ogre_plugins.cfg.in
     ${CMAKE_BINARY_DIR}/ogre_plugins.cfg

[adrian_broher]

A buddy of mine said this should fix that:

Well, now that's embarrassing… missing such an obvious error. Thank your buddy for pointing this out. The actual fix looks somewhat different, but your suggestion pointed me the into right direction.

Fixed in r6952.