Page 1 of 1

Issues compiling/running freeorion

Posted: Sat Mar 27, 2010 1:41 pm
by tomboy64
When I have compiled freeorion, running it results in

Code: Select all

~ $ /usr/games/freeorion/freeorion
freeorion: /usr/include/boost/thread/pthread/recursive_mutex.hpp:72: void boost::recursive_mutex::unlock(): Assertion `!pthread_mutex_unlock(&m)' failed.
Abgebrochen
If somebody wishes for it I can create a debug-build and run it in gdb. If the reason is known and someone is working on a fix I won't bother.

I built against:
gigi rev 804
boost 1.42.0
ogre 1.6.5

Re: Issues compiling/running freeorion

Posted: Sat Mar 27, 2010 5:20 pm
by tomboy64
Another thing is, when running "make install" it actually copies the binaries freeorion/freeoriond/freeorionca to /usr/local/ and all the rest to /usr/local/default/default. By applying the attached patch it's possible to reduce this to 1 default.

The proper way, imho, would be to introduce 2 variables, for example INSTALL_DATA_DIR and INSTALL_BIN_DIR, which are listed on top and easily modifyable and which regulate the install directory.

Re: Issues compiling/running freeorion

Posted: Sun Mar 28, 2010 1:48 am
by tzlaine
tomboy64 wrote:When I have compiled freeorion, running it results in

Code: Select all

~ $ /usr/games/freeorion/freeorion
freeorion: /usr/include/boost/thread/pthread/recursive_mutex.hpp:72: void boost::recursive_mutex::unlock(): Assertion `!pthread_mutex_unlock(&m)' failed.
Abgebrochen
If somebody wishes for it I can create a debug-build and run it in gdb. If the reason is known and someone is working on a fix I won't bother.

I built against:
gigi rev 804
boost 1.42.0
ogre 1.6.5
I have no idea what's going on here. If you'd like to investigate, please do.

Re: Issues compiling/running freeorion

Posted: Sun Mar 28, 2010 1:52 am
by tomboy64

Code: Select all

(gdb) bt
#0  0xb7fe1424 in __kernel_vsyscall ()
#1  0xb72316e0 in raise () from /lib/libc.so.6
#2  0xb7232f15 in abort () from /lib/libc.so.6
#3  0xb722a90e in __assert_fail () from /lib/libc.so.6
#4  0xb789af71 in Ogre::LogManager::createLog(std::string const&, bool, bool, bool) () from /usr/lib/libOgreMain-1.6.5.so
#5  0x08768992 in mainSetupAndRunOgre ()
    at /var/tmp/portage/games-strategy/freeorion-9999/work/freeorion-9999/FreeOrion/client/human/chmain.cpp:171
#6  0x08769f7c in main (argc=Cannot access memory at address 0x2b23
)
    at /var/tmp/portage/games-strategy/freeorion-9999/work/freeorion-9999/FreeOrion/client/human/chmain.cpp:73

Re: Issues compiling/running freeorion

Posted: Sun Mar 28, 2010 1:55 am
by tzlaine
tomboy64 wrote:Another thing is, when running "make install" it actually copies the binaries freeorion/freeoriond/freeorionca to /usr/local/ and all the rest to /usr/local/default/default. By applying the attached patch it's possible to reduce this to 1 default.
I didn't write the CMake install targets with installing into useful places on a Linux machine in mind. The install locations are purely for making Win32 binary installers. If you want to make a change, and I'm all for that, please make it using if (WIN32) [the old stuff] else () [your new stuff] endif ().
The proper way, imho, would be to introduce 2 variables, for example INSTALL_DATA_DIR and INSTALL_BIN_DIR, which are listed on top and easily modifyable and which regulate the install directory.
I'd prefer to see things get installed in a canonical location every time, under ${prefix}:

${prefix}/bin
${prefix}/lib
${prefix}/doc
${prefix}/share

If we need to add /freeorion to one or more of these, that's fine (e.g. ${prefix}/share/freeorion/default). But I don't want users to need to know what the values of INSTALL_DATA_DIR and INSTALL_BIN_DIR were if they want to look at some files we ask the m to look at during a bughunt, or do two installations, changing the values in between, and not knowing which files are being picked up by FO.

Re: Issues compiling/running freeorion

Posted: Sun Mar 28, 2010 1:56 am
by tzlaine
tomboy64 wrote:

Code: Select all

(gdb) bt
#0  0xb7fe1424 in __kernel_vsyscall ()
#1  0xb72316e0 in raise () from /lib/libc.so.6
#2  0xb7232f15 in abort () from /lib/libc.so.6
#3  0xb722a90e in __assert_fail () from /lib/libc.so.6
#4  0xb789af71 in Ogre::LogManager::createLog(std::string const&, bool, bool, bool) () from /usr/lib/libOgreMain-1.6.5.so
#5  0x08768992 in mainSetupAndRunOgre ()
    at /var/tmp/portage/games-strategy/freeorion-9999/work/freeorion-9999/FreeOrion/client/human/chmain.cpp:171
#6  0x08769f7c in main (argc=Cannot access memory at address 0x2b23
)
    at /var/tmp/portage/games-strategy/freeorion-9999/work/freeorion-9999/FreeOrion/client/human/chmain.cpp:73
Something fishy is happening, if you're seeing "argc=Cannot access memory at address 0x2b23". You've got ABI issues, two versions of the same lib being linked in, or something wonky like that.

Re: Issues compiling/running freeorion

Posted: Sun Mar 28, 2010 2:38 am
by tomboy64
any idea what to look for?
i'm rebuilding ogre and gigi right now, then look again.

Re: Issues compiling/running freeorion

Posted: Sun Mar 28, 2010 2:47 am
by Geoff the Medio
Make sure all the libraries you're linking against were built with the same version of the compiler, and that all the libraries you're linking against are consistent with eachother and the versions of libraries that other libraries link against. ldd is useful for this. I'd start with checking how libOgreMain was built.

disclaimer: I may not know what I'm talking about.

Re: Issues compiling/running freeorion

Posted: Sun Mar 28, 2010 7:54 pm
by tzlaine
tomboy64 wrote:any idea what to look for?
i'm rebuilding ogre and gigi right now, then look again.
Unfortunately, no. My comment was just a guess. It could also be that the stack was corrupted by whatever bug exists, and that's why argv was munged. Sorry I can't be more helpful, but there's a lot that could go wrong during the build, or between the build and execution. ldd is your friend, as Geoff noted.

Re: Issues compiling/running freeorion

Posted: Tue Mar 30, 2010 12:57 pm
by kroddn
Seems to me a problem that tzlaine mentioned: wrong headers/libs used for compiling/linking.

If you use your own compiled boost, make sure there's no boost installed by your distribution, which are include-files taken from. I had a similar problem when compiling on ubuntu9.10, and that's one reason why I use a clean distribution and compile every FO-dependency manually.

The best thing for getting a clean build is: remove the whole FreeOrion tree and checkout it again.

Re: Issues compiling/running freeorion

Posted: Fri May 21, 2010 5:21 am
by 107
tomboy64 wrote:

Code: Select all

~ $ /usr/games/freeorion/freeorion
freeorion: /usr/include/boost/thread/pthread/recursive_mutex.hpp:72: void boost::recursive_mutex::unlock(): Assertion `!pthread_mutex_unlock(&m)' failed.
Abgebrochen
Recompile your Ogre without threads support!

gentoo ex.:

Code: Select all

USE="-threads" emerge -1 ogre

Re: Issues compiling/running freeorion

Posted: Fri Oct 21, 2011 3:38 am
by Geoff the Medio
tzlaine wrote:
tomboy64 wrote:Another thing is, when running "make install" it actually copies the binaries freeorion/freeoriond/freeorionca to /usr/local/ and all the rest to /usr/local/default/default. By applying the attached patch it's possible to reduce this to 1 default.
I didn't write the CMake install targets with installing into useful places on a Linux machine in mind. The install locations are purely for making Win32 binary installers. If you want to make a change, and I'm all for that, please make it using if (WIN32) [the old stuff] else () [your new stuff] endif ().
The proper way, imho, would be to introduce 2 variables, for example INSTALL_DATA_DIR and INSTALL_BIN_DIR, which are listed on top and easily modifyable and which regulate the install directory.
I'd prefer to see things get installed in a canonical location every time, under ${prefix}:

${prefix}/bin
${prefix}/lib
${prefix}/doc
${prefix}/share

If we need to add /freeorion to one or more of these, that's fine (e.g. ${prefix}/share/freeorion/default). But I don't want users to need to know what the values of INSTALL_DATA_DIR and INSTALL_BIN_DIR were if they want to look at some files we ask the m to look at during a bughunt, or do two installations, changing the values in between, and not knowing which files are being picked up by FO.
Guy on IRC, dansan, complained of the same Linux make install default/default issue, and also the lack of ogre_plugins.cfg when he built out of source tree. If it's not going to have a working use in Linux due to nobody wanting to code it properly in CMake, it might be better to just have an error message be generated, which I assume is a bit easier to set up.

Re: Issues compiling/running freeorion

Posted: Sat Oct 22, 2011 12:51 am
by Daniel Santos
Hey guys. So yeah, I posted a patch, but I guess I didn't check to make sure it doesn't break windows. So instead, I think the CMake just needs to be totally overhauled for *nix. I know there's a Gentoo ebuild, I'm curious to see what they are doing there (maybe they've done part of our work for us in the form of patches to the CMake file). Let me cover GiGi first
  • The default CMAKE_INSTALL_PREFIX should be "/usr" and not "/usr/local" (applies to freeorion too)
  • doc -> ${CMAKE_INSTALL_PREFIX}/share/doc/GG-<version> (at least on Gentoo, other distros may omit version)
  • include -> ${CMAKE_INSTALL_PREFIX}/include (where it installs now)
  • lib -> ${CMAKE_INSTALL_PREFIX}/lib (also where it is now)
Then, for FreeOrion:
  • Executables generally go in /usr/bin. However, most distros have a separate place for games. On Gentoo, it's /usr/games/bin, but on Debian, it's just /usr/games. So these should be installed into ${CMAKE_INSTALL_PREFIX}/games/bin, or at the very least, ${CMAKE_INSTALL_PREFIX}/bin, but never just ${CMAKE_INSTALL_PREFIX}.
  • Game data should go into (again, based on distro) one of /usr/share/games/<package-name> or just /usr/share/<package-name>. So default -> ${CMAKE_INSTALL_PREFIX}/share/games/freeorion/default.
  • I can see ogre_plugins.cfg being something that users will almost certainly never have to modify, so it probably belongs in /etc/games/freeorion.
  • However, OISInput.cfg appears to be something that I can see some users possibly needing to modify at some point, especially for troubleshooting (Debian testing gave us a bad xorg server last month, for instance -- breakages can and do happen). So probably install it into /etc/games/freeorion but also allow user to override it by copying it to their ~/.freeorion directory (or edit the one in /etc, if they have root privs). This is a common scheme on *nix: first look in $HOME/.someconfig, then /etc first (some programs will also check the current directory before $HOME).
  • I would ask you to consider not assuming that GiGi is going to be under the GG directory. The main reason is that it is a feature-rich library in it's own right and, while I don't know of any other game projects that use it at the moment, I'm sure there will be projects that do. Thus, I propose that it's better if it's allowed to be it's own package entirely and that CMake be told where it's headers & libs are. (If this is already the case, then sorry, please ignore this bullet point!!)
On a side note about the default data directory (and this is just a future consideration thing), I presume that there can be "games" other than default. If this is the case, then the default should still be installed under /usr/share/games/freeorion/default (read-only to users) and a search path setup so that they can be pulled from /usr/share/games/freeorion and ${HOME}/.freeorion/data and maybe some other places (if needed) as well. There may be packages (.deb, .rpm, .ebuild, etc.) in the future that installs these system-wide -- that is the common mechanism used in Linux at least. In these cases, I'm not certain what the common practice is, I guess it might install them directly into /usr/share/games/freeorion (I think that's what Wesnoth does, not certain though).

Re: Issues compiling/running freeorion

Posted: Sat Oct 22, 2011 1:14 am
by Daniel Santos
gah! you got me learning CMake now.