Orxonox goes C++11

[flozi]

Ok, the warning is gone now on my system.
But if I test your two snippets, none of them produce a warning.

However, here's a bigger issue:
I tried compiling on Tardis and it failed at configuring cmake. Compiler is

Code: Select all

gcc (Debian 4.9.2-10) 4.9.2

, cmake is

Code: Select all

cmake version 3.0.2

.
Here's the complete output: http://pastebin.com/dW9rLGR5.

Unfortunately I have zero understanding of the whole build process of orxonox and cmake in general, so I can't help in investigating the cause for this.
It might be relevant that the Tardis have most like upgraded their debian version, since they have a different background image now. the new version is 'Debian GNU/Linux 8 (jessie) 64-bit'. I don't know what version they were before.

[muemart]

Looks like gmake doesn't work. I tried running it outside of cmake and I got the same error (missing libguile.so), so I don't think this is a cmake problem.

[x3n]

Yes I noticed that too when I tried to compile on tardis yesterday.
Looks like something ISG should be able to fix (but maybe they need a hint)

Anyway, I'm glad they upgraded gcc to version 4.9, looks like we're on track.


Thanks for testing the snippets @flozi. It seems that gcc indeed fixed the warning in the given snippet, but our (real) case is probably a little bit more obscure since it includes even more levels of virtual inheritance. I'll try it again when I have a more recent version of gcc.

[fvultier]

I also tried to build Orxonox on Tardis today. Still the same error message.

[flozi]

Today I asked the ISG support about it and they managed to fix gmake.
However, it still doesn't compile. Cmake works now, but when compiling we get a new error:
http://pastebin.com/kWrdZXGs
This one seems to be caused by some of our own files. (this happens with trunk)


I also checked if the error went away when trying an older branch, but here I get a different error.
This error doesn't seem to be caused by our code, so I might need to bother the ISG once more:
http://pastebin.com/HsyubhgY

Any ideas?

[flozi]

Ok I think I might know where the problem is coming from. The file "trunk/cmake/LibraryConfigTardis.cmake" is very suspicious.
It defines all paths used on tardis and since the new upgrade some are not right anymore. For instance, we're using "boost-1.42.0-bs", while the current version on tardis would be 1.55.

I hope correcting those paths will fix the problem. (I can't test that right now)

[x3n]

I'm currently looking into it. I guess the old tardis-specific version of boost is outdated (and doesn't work with c++11). Also sometimes an include of a standard header is missing in our code.

[x3n]

done. http://www.orxonox.net/changeset/11097

[fvultier]

Good work! Looking forward to test it tomorrow. I'll also test the tutorial branch which we need for the PPS.

[flozi]

Alright, we're getting there. Compiling now works successful. Woohoo!
Next problem is already here though. When trying to start orxonox it immediately crashes, here are the logs:
http://pastebin.com/0uSxppt6

[x3n]

I cannot reproduce that because I can't start orxonox on tardis via the terminal anyway.

But here's what I know:
CEGUI uses an XML parser to read the GUI definitions. There are apparently four parsers:

Code: Select all

$ ls /usr/pack/cegui-0.6.2-sd/amd64-debian-linux5.0/lib/libCEGUI**Parser*.so
/usr/pack/cegui-0.6.2-sd/amd64-debian-linux5.0/lib/libCEGUIExpatParser.so
/usr/pack/cegui-0.6.2-sd/amd64-debian-linux5.0/lib/libCEGUITinyXMLParser.so
/usr/pack/cegui-0.6.2-sd/amd64-debian-linux5.0/lib/libCEGUILibxmlParser.so
/usr/pack/cegui-0.6.2-sd/amd64-debian-linux5.0/lib/libCEGUIXercesParser.so

In Orxonox we tell CEGUI to use "XercesParser" (see GUIManager.cc line 379).
Apparently this doesn't work (anymore?) because the xerces library cannot be found (and you probably remember that the ISG guy told you that we're using an old and unmaintained version of cegui).

So option a) is to use a different parser. I don't know WHY we force XercesParser in GUIManager.cc, maybe there's a reason but maybe it's just random. Try another parser anyway. I would go with "TinyXMLParser" first.

Option b) is to use another version of CEGUI. Apart from that old version, tardis offers also a newer version of CEGUI (v0.7). I made some attempts to compile with it, but there are several issues. First of all, libCEGUItoluapp.so is missing in the new version. So we'd probably have to compile our own version of CEGUI to make it work.

I guess that we'll go with option b) anyway sooner or later. But until then you can try to make it work with option a).

[flozi]

Not at eth, so I couldn't try option a) yet. Besides, option b) sounds better anyway.

Interestingly, on my machine I also don't have libCEGUItoluapp.so and on my machine everything works perfectly, so this alone can't be it. This is what I've got: http://pastebin.com/7zJEFiFx
This seems to be identical to what's on tardis.
So why does it work on my machine and not on tardis, what else could possibly be different?


Btw, how do you even compile via terminal (ssh)? I know trunk now compiles on tardis, but when I try over ssh I can't get past the cmake problem:

Code: Select all

Could NOT find CEGUI (version requirements: at least 0.6) (missing: CEGUI_TOLUA_LIBRARY_OPTIMIZED) (Required is at least version "0.6")

[x3n]

Do you have any changes in the cmake scripts on tardis? Because your error is exactly what I'm talking about (tolua++ missing). But I only get this error when I try to use the new CEGUI version.

Btw, tolua++ can have many names (according to our cmake script): CEGUItoluapp tolua++ ceguitolua++ tolua++5.1
Maybe that's the reason why you don't see it on your system, but it's definitely there somewhere. Just look in CMakeCache.txt for CEGUI_TOLUA_LIBRARY_OPTIMIZED to find the path.

[muemart]

Why are depending on CEGUI to provide tolua++, anyway? The source is like six files, only depends on lua, and we already have a folder external/tolua... I'm also not sure if we can assume that tolua++ is installed when CEGUI is, because it might be an optional dependency.

[x3n]

Good question, I don't know. Maybe CEGUI itself needs tolua++ for certain features? I never really touched this part of orxonox.
But we can give it a try. If it works, I'm ok with adding tolua++ to our external sources.