Issues compiling/running freeorion

Questions, problems and discussion about compiling FreeOrion.

Moderators: Oberlus, Oberlus

Post Reply
Message
Author
tomboy64
Space Floater
Posts: 23
Joined: Mon Jan 07, 2008 5:14 pm

Issues compiling/running freeorion

#1 Post by tomboy64 » Sat Mar 27, 2010 1:41 pm

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

tomboy64
Space Floater
Posts: 23
Joined: Mon Jan 07, 2008 5:14 pm

Re: Issues compiling/running freeorion

#2 Post by tomboy64 » Sat Mar 27, 2010 5:20 pm

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.
Attachments

[The extension patch has been deactivated and can no longer be displayed.]


User avatar
tzlaine
Programming Lead Emeritus
Posts: 1092
Joined: Thu Jun 26, 2003 1:33 pm

Re: Issues compiling/running freeorion

#3 Post by tzlaine » Sun Mar 28, 2010 1:48 am

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.

tomboy64
Space Floater
Posts: 23
Joined: Mon Jan 07, 2008 5:14 pm

Re: Issues compiling/running freeorion

#4 Post by tomboy64 » Sun Mar 28, 2010 1:52 am

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

User avatar
tzlaine
Programming Lead Emeritus
Posts: 1092
Joined: Thu Jun 26, 2003 1:33 pm

Re: Issues compiling/running freeorion

#5 Post by tzlaine » Sun Mar 28, 2010 1:55 am

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.

User avatar
tzlaine
Programming Lead Emeritus
Posts: 1092
Joined: Thu Jun 26, 2003 1:33 pm

Re: Issues compiling/running freeorion

#6 Post by tzlaine » Sun Mar 28, 2010 1:56 am

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.

tomboy64
Space Floater
Posts: 23
Joined: Mon Jan 07, 2008 5:14 pm

Re: Issues compiling/running freeorion

#7 Post by tomboy64 » Sun Mar 28, 2010 2:38 am

any idea what to look for?
i'm rebuilding ogre and gigi right now, then look again.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12480
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Issues compiling/running freeorion

#8 Post by Geoff the Medio » Sun Mar 28, 2010 2:47 am

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.

User avatar
tzlaine
Programming Lead Emeritus
Posts: 1092
Joined: Thu Jun 26, 2003 1:33 pm

Re: Issues compiling/running freeorion

#9 Post by tzlaine » Sun Mar 28, 2010 7:54 pm

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.

User avatar
kroddn
Static Linker
Posts: 347
Joined: Thu Jun 28, 2007 10:28 am

Re: Issues compiling/running freeorion

#10 Post by kroddn » Tue Mar 30, 2010 12:57 pm

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.

107
Space Krill
Posts: 4
Joined: Fri May 21, 2010 4:57 am

Re: Issues compiling/running freeorion

#11 Post by 107 » Fri May 21, 2010 5:21 am

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

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12480
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Issues compiling/running freeorion

#12 Post by Geoff the Medio » Fri Oct 21, 2011 3:38 am

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.

Daniel Santos
Space Floater
Posts: 28
Joined: Sun Nov 15, 2009 8:15 am

Re: Issues compiling/running freeorion

#13 Post by Daniel Santos » Sat Oct 22, 2011 12:51 am

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).

Daniel Santos
Space Floater
Posts: 28
Joined: Sun Nov 15, 2009 8:15 am

Re: Issues compiling/running freeorion

#14 Post by Daniel Santos » Sat Oct 22, 2011 1:14 am

gah! you got me learning CMake now.

Post Reply