Tardis compability

[beni]

Very urgent and very preemptive bug report today.

NEW LINUX OS IN ETL/E/11, ETL/F/11 AND ETZ/D/96
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

### [deutsch unten]
###
### Dear users of the computer rooms ETL/E/11, ETL/F/11 and ETZ/D/96.
###
### We are migrating the computers in the rooms mentioned above from Debian
### Etch 4.0 to Debian Lenny 5.0. The migration of the tardis cluster will
### be done on 27th of January.
###
### Please report any inconvenience or problems encountered to our support
### address <mailto:support@ee.ethz.ch>.
###
### Yours,
### IT Support Group D-ITET
### support@ee.ethz.ch
###
### -----
###
### Liebe Benutzer der Computerraeume ETL/E/11, ETL/F/11 und ETZ/D/96.
###
### Wir werden die Computer in den oben erwaehnten Raeumen von Debian Etch
### 4.0 auf Debian Lenny 5.0 migrieren. Die Migration des tardis Clusters
### wird am 27. Januar stattfinden.
###
### Wir bitten Sie aus der Migration fuer Sie entstehenden Unannehmlichkeiten
### oder auftauchende Probleme an <mailto:support@ee.ethz.ch> zu melden.
###
### Freundliche Gruesse,
### Informatik Support Gruppe D-ITET
### support@ee.ethz.ch

We have to check if Orxonox still compiles properly on the new systems. Overall this is good news for us. It could mean that we do not have to treat the Tardis case individually that much anymore. Of course it is important that the new PPS can start in February.

[greenman]

they want to migrate the systems today, so i think i'll make a fresh install today and see whether it compiles... of course i can't tell whether it runs and everything works fine with ogre ...

will anyone be around etl in the next days / weeks to test this ?

[x3n]

maybe I'm there tomorrow, but not guarantee

[greenman]

there really seems to be a problem with the actual cmake configuration

however, if i exclude the tardis-hacks (in cmake/LibraryConfigTardis.cmake) for alut, ogg, vorbis and openal cmake runs successfully.

there seem to be some inconsistencies with cmake and boost (partially uses system libraries, partially sepp libraries ...) which result in a linker error ...

[x3n]

there really seems to be a problem with the actual cmake configuration

however, if i exclude the tardis-hacks (in cmake/LibraryConfigTardis.cmake) for alut, ogg, vorbis and openal cmake runs successfully.

there seem to be some inconsistencies with cmake and boost (partially uses system libraries, partially sepp libraries ...) which result in a linker error ...

can you tell me what I have to change to make it compile? i don't feel like fidling with tardis specific hacks today

[greenman]

apply the attached patch (boost problem still persists)

problem with boost is the following:

locally debian lenny has 1.34 installed
but because we need at least 1.35 we use the sepp package in /usr/pack/boost-1.36....
now cmake uses the files in the sepp package but doesn't find any debug libraries, so it uses the locally available boost libraries of version 1.34 which causes linker (and other) errors when building debug version

edit: seems like attaching didn't work, will post the code here

Code: Select all

Index: cmake/LibraryConfigTardis.cmake
===================================================================
--- cmake/LibraryConfigTardis.cmake	(revision 6459)
+++ cmake/LibraryConfigTardis.cmake	(working copy)
@@ -45,11 +45,11 @@
   SET(BOOST_LIBRARYDIR "/usr/pack/boost-1.36.0-sd/i686-debian-linux4.0/lib")
   SET(ENV{CEGUIDIR}    "/usr/pack/cegui-0.6.2-sd;/usr/pack/cegui-0.6.2-sd/i686-debian-linux4.0")
   SET(ENV{ENETDIR}     "/usr/pack/enet-1.2-sd;/usr/pack/enet-1.2-sd/i686-debian-linux4.0")
-  SET(ENV{ALUTDIR}     "/usr/pack/openal-0.0.8-cl;/usr/pack/openal-0.0.8-cl/i686-debian-linux3.1")
-  SET(ENV{OGGDIR}      "/usr/pack/oggvorbis-1.0-ds;/usr/pack/oggvorbis-1.0-ds/i686-debian-linux3.0")
-  SET(ENV{VORBISDIR}   "/usr/pack/oggvorbis-1.0-ds;/usr/pack/oggvorbis-1.0-ds/i686-debian-linux3.0")
+#  SET(ENV{ALUTDIR}     "/usr/pack/openal-0.0.8-cl;/usr/pack/openal-0.0.8-cl/i686-debian-linux3.1")
+#  SET(ENV{OGGDIR}      "/usr/pack/oggvorbis-1.0-ds;/usr/pack/oggvorbis-1.0-ds/i686-debian-linux3.0")
+#  SET(ENV{VORBISDIR}   "/usr/pack/oggvorbis-1.0-ds;/usr/pack/oggvorbis-1.0-ds/i686-debian-linux3.0")
   SET(ENV{LUA_DIR}     "/usr/pack/lua-5.1.4-sd;/usr/pack/lua-5.1.4-sd/i686-debian-linux4.0")
   SET(ENV{OGRE_HOME}   "/usr/pack/ogre-1.4.9-sd;/usr/pack/ogre-1.4.9-sd/i686-debian-linux4.0")
-  SET(ENV{OPENALDIR}   "/usr/pack/openal-0.0.8-cl;/usr/pack/openal-0.0.8-cl/i686-debian-linux3.1")
+#  SET(ENV{OPENALDIR}   "/usr/pack/openal-0.0.8-cl;/usr/pack/openal-0.0.8-cl/i686-debian-linux3.1")
   #SET(TCL_INCLUDE_PATH "/usr/pack/tcltk-8.4.9.linux-mo/include")
 ENDIF(TARDIS)

[x3n]

k thanks, I gave it a try, but couldn't work around the boost problem and I'm heading home to lunch now.

[greenman]

the next time you can try to edit the reference to the debug libraries manually:
- instead of cmake-2.6.4 .. make ccmake-2.6.4 ..
- press t to show the advanced variables
- configure (c) and afterwards try to remove the boost-debug entries that point to /usr/lib with Boost_XXXXXX_LIBRARY_DEBUG-NOTFOUND (eg Boost_FILESYSTEM_LIBRARY_DEBUG-NOTFOUND)
- then generate (g) if possible or configure again (c) and then (g)

hope that helps

[x3n]

1. you can use "cmake" and "ccmake" directly now, they updated the default version
2. i tried to do a release build instead of a debug build, I assumed this would do the same thing like your proposal, but I didn't worked.

[greenman]

cmake now has default version 2.6.0 which has bugs and doesn't work for us (at least it didn't when i tried yesterday)

[1337]

CMake 2.6.0 has an old FindBoost script. If we want it to work, we'd have to put some effort into that. But honestly, why would Debian use the most buggy 2.6 version anyhow?

About the actual problem: I can only see one solution. And that would be to manually (by means of a loop) remove the debug libraries.
Or we could adjust FindBoost. But that would be one more internal dependency.

[greenman]

i don't really like the 2nd one ...
we could also ask the isg to install add debug libraries, but they'd probably add them to another sepp folder and we'd have exactly the same problem again ...
we could also ask them to remove the local boost-version, but i doubt that they will be pleased

[1337]

Unfortunately the find script doesn't seem to process multiple library directories.
Ergo we're still stuck ^^

Probably removing them is the best alternative.

[greenman]

i also think so ... shouldn't be hard to do that ?!

edit: we have another problem (think we've encountered this one before ...):
tried to build in release mode and got the following linker error:

Code: Select all

/usr/bin/../lib/libOgreMain.so: undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, int)@GLIBCXX_3.4.9'
/usr/bin/../lib/libOgreMain.so: undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::basic_ostream<char, std::char_traits<char> >::_M_insert<bool>(bool)@GLIBCXX_3.4.9'
/usr/bin/../lib/libOgreMain.so: undefined reference to `std::basic_istream<char, std::char_traits<char> >& std::basic_istream<char, std::char_traits<char> >::_M_extract<float>(float&)@GLIBCXX_3.4.9'
/usr/bin/../lib/libOgreMain.so: undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::basic_ostream<char, std::char_traits<char> >::_M_insert<unsigned long>(unsigned long)@GLIBCXX_3.4.9'
/usr/bin/../lib/libOgreMain.so: undefined reference to `std::basic_istream<char, std::char_traits<char> >& std::basic_istream<char, std::char_traits<char> >::_M_extract<unsigned int>(unsigned int&)@GLIBCXX_3.4.9'
/usr/bin/../lib/libOgreMain.so: undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::basic_ostream<char, std::char_traits<char> >::_M_insert<long>(long)@GLIBCXX_3.4.9'
/usr/bin/../lib/libOgreMain.so: undefined reference to `std::basic_istream<char, std::char_traits<char> >& std::basic_istream<char, std::char_traits<char> >::_M_extract<unsigned long>(unsigned long&)@GLIBCXX_3.4.9'
/usr/bin/../lib/libOgreMain.so: undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::basic_ostream<char, std::char_traits<char> >::_M_insert<void const*>(void const*)@GLIBCXX_3.4.9'
/usr/bin/../lib/libOgreMain.so: undefined reference to `std::basic_istream<char, std::char_traits<char> >& std::basic_istream<char, std::char_traits<char> >::_M_extract<long>(long&)@GLIBCXX_3.4.9'
/usr/bin/../lib/libOgreMain.so: undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::basic_ostream<char, std::char_traits<char> >::_M_insert<double>(double)@GLIBCXX_3.4.9'

didn't we have this error some time ago in combination with ogre-1.6 ? (my build was with 1.4.9 though)

[greenman]

as the next semester starts tomorrow we should really stress this point...

any ideas / news?