Summary: | dev-games/ogre-1.7.4: OgreXMLConverter segfaults when enabling the threads USE flag | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | vax456 |
Component: | [OLD] Games | Assignee: | Gentoo Games <games> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | azamat.hackimov, O01eg |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 412675 |
Description
vax456
2012-04-15 01:34:54 UTC
got same thing with +threads. backtrace: 0x00007ffff77eac60 in Ogre::EdgeListBuilder::buildTrianglesEdges(Ogre::EdgeListBuilder::Geometry const&) () from /usr/lib64/libOgreMain.so.1.7.4 (gdb) bt #0 0x00007ffff77eac60 in Ogre::EdgeListBuilder::buildTrianglesEdges(Ogre::EdgeListBuilder::Geometry const&) () from /usr/lib64/libOgreMain.so.1.7.4 #1 0x00007ffff77eb4ef in Ogre::EdgeListBuilder::build() () from /usr/lib64/libOgreMain.so.1.7.4 #2 0x00007ffff78af992 in Ogre::Mesh::buildEdgeList() () from /usr/lib64/libOgreMain.so.1.7.4 #3 0x000000000041dc2f in XMLToBinary(XmlOptions) () #4 0x0000000000420821 in main () According Ogre documentation (http://www.ogre3d.org/tikiwiki/tiki-index.php?page=CMake+Quick+Start+Guide&tikiversion=Linux), in Linux available only two threading models: 0 - Threading is disabled 2 - Threading with background resource preparation Mode 1 (Threading with full background resource loading) in Linux is NOT SUPPORTED. OGRE_CONFIG_THREADS is threestate variable. Meantime, in ebuild switch threading only with two - 0 or 1. So we need change this to 0 or 2: if use threads ; then local f for f in poco tbb boost ; do use ${f} || continue mycmakeargs+=( -DOGRE_CONFIG_THREADS=2 -DOGRE_CONFIG_THREAD_PROVIDER=${f} ) break done else mycmakeargs+=( -DOGRE_CONFIG_THREADS=0 ) fi Additionly, error mentonied here http://www.ogre3d.org/mantis/view.php?id=425 is cause of wrong choiced threading model. Patch ogre-1.7.4-threading.patch is useless there. (In reply to comment #2) > According Ogre documentation > (http://www.ogre3d.org/tikiwiki/tiki-index. > php?page=CMake+Quick+Start+Guide&tikiversion=Linux), in Linux available only > two threading models: > 0 - Threading is disabled > 2 - Threading with background resource preparation > > Mode 1 (Threading with full background resource loading) in Linux is NOT > SUPPORTED. > > OGRE_CONFIG_THREADS is threestate variable. Meantime, in ebuild switch > threading only with two - 0 or 1. So we need change this to 0 or 2: > > if use threads ; then > local f > for f in poco tbb boost ; do > use ${f} || continue > mycmakeargs+=( -DOGRE_CONFIG_THREADS=2 > -DOGRE_CONFIG_THREAD_PROVIDER=${f} ) > break > done > else > mycmakeargs+=( -DOGRE_CONFIG_THREADS=0 ) > fi Right, that would definitely be cleaner/safer. However I cannot confirm that threading is _ever_ set to "1", meaning "full". look at the code: ##### if (OGRE_CONFIG_THREADS EQUAL 0) set(_threads "none") elseif (OGRE_CONFIG_THREADS EQUAL 1) set(_threads "full (${OGRE_CONFIG_THREAD_PROVIDER})") else () set(_threads "background (${OGRE_CONFIG_THREAD_PROVIDER})") endif () ##### since "OGRE_CONFIG_THREADS" is either "ON" or "OFF" it results in one of these: Threading support: background (none) Threading support: background (boost) Threading support: background (poco) Threading support: background (tbb) however that seems to break the following snippet because "ON" does not suffice "GREATER 0": ##### if (OGRE_CONFIG_THREADS GREATER 0) set(OGRE_CFLAGS "-pthread") set(OGRE_ADDITIONAL_LIBS "${OGRE_ADDITIONAL_LIBS} -lpthread") endif () ##### And that again breaks the pkgconfig files which are missing e.g. "-pthread". Seems no one noticed. This should do for that particular problem: - $(cmake-utils_use threads OGRE_CONFIG_THREADS) + $(usex threads "-DOGRE_CONFIG_THREADS=2" "-DOGRE_CONFIG_THREADS=0") Didn't check the other issue yet. plz check if your OgreXMLConverter issue is related to bug https://bugs.gentoo.org/show_bug.cgi?id=418269 nah, seems not. OgreXMLConverter is just internal anyway. I can confirm that issue. Also on mesh -> xml still broken with 1.8.1? No reply. for the book: does not happen with 1.8.1 |