FreeOrion

Forums for the FreeOrion project
It is currently Tue Sep 30, 2014 7:51 pm

All times are UTC




Post new topic Reply to topic  [ 14 posts ] 
Author Message
PostPosted: Sat Mar 27, 2010 1:41 pm 
Offline
Space Floater

Joined: Mon Jan 07, 2008 5:14 pm
Posts: 23
When I have compiled freeorion, running it results in

Code:
~ $ /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


Top
 Profile  
 
PostPosted: Sat Mar 27, 2010 5:20 pm 
Offline
Space Floater

Joined: Mon Jan 07, 2008 5:14 pm
Posts: 23
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:
CMakeList-install.patch [417 Bytes]
Downloaded 82 times
Top
 Profile  
 
PostPosted: Sun Mar 28, 2010 1:48 am 
Offline
Programming Lead Emeritus
User avatar

Joined: Thu Jun 26, 2003 1:33 pm
Posts: 1092
tomboy64 wrote:
When I have compiled freeorion, running it results in

Code:
~ $ /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.


Top
 Profile  
 
PostPosted: Sun Mar 28, 2010 1:52 am 
Offline
Space Floater

Joined: Mon Jan 07, 2008 5:14 pm
Posts: 23
Code:
(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


Top
 Profile  
 
PostPosted: Sun Mar 28, 2010 1:55 am 
Offline
Programming Lead Emeritus
User avatar

Joined: Thu Jun 26, 2003 1:33 pm
Posts: 1092
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 ().

Quote:
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.


Top
 Profile  
 
PostPosted: Sun Mar 28, 2010 1:56 am 
Offline
Programming Lead Emeritus
User avatar

Joined: Thu Jun 26, 2003 1:33 pm
Posts: 1092
tomboy64 wrote:
Code:
(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.


Top
 Profile  
 
PostPosted: Sun Mar 28, 2010 2:38 am 
Offline
Space Floater

Joined: Mon Jan 07, 2008 5:14 pm
Posts: 23
any idea what to look for?
i'm rebuilding ogre and gigi right now, then look again.


Top
 Profile  
 
PostPosted: Sun Mar 28, 2010 2:47 am 
Offline
Programming, Design, and De Facto Lead
User avatar

Joined: Wed Oct 08, 2003 1:33 am
Posts: 10146
Location: Munich
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.


Top
 Profile  
 
PostPosted: Sun Mar 28, 2010 7:54 pm 
Offline
Programming Lead Emeritus
User avatar

Joined: Thu Jun 26, 2003 1:33 pm
Posts: 1092
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.


Top
 Profile  
 
PostPosted: Tue Mar 30, 2010 12:57 pm 
Offline
Static Linker
User avatar

Joined: Thu Jun 28, 2007 10:28 am
Posts: 347
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.


Top
 Profile  
 
PostPosted: Fri May 21, 2010 5:21 am 
Offline
Space Krill

Joined: Fri May 21, 2010 4:57 am
Posts: 4
tomboy64 wrote:
Code:
~ $ /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:
USE="-threads" emerge -1 ogre


Top
 Profile  
 
PostPosted: Fri Oct 21, 2011 3:38 am 
Offline
Programming, Design, and De Facto Lead
User avatar

Joined: Wed Oct 08, 2003 1:33 am
Posts: 10146
Location: Munich
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 ().

Quote:
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.


Top
 Profile  
 
PostPosted: Sat Oct 22, 2011 12:51 am 
Offline
Space Floater

Joined: Sun Nov 15, 2009 8:15 am
Posts: 28
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).


Top
 Profile  
 
PostPosted: Sat Oct 22, 2011 1:14 am 
Offline
Space Floater

Joined: Sun Nov 15, 2009 8:15 am
Posts: 28
gah! you got me learning CMake now.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 14 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group