I have now checked out and built the current OSG trunk, and can report that
statically built OSG now terminates properly without any errors in both debug
and release. Thank you very much for your help. :-)
Your RenderBin_195.cpp hotfix, however, causes an compile error when
incorporating it
I've just discovered a potential solution for the initialization order for
static objects. You can use the depends_on-pattern to let your classes
inherit their dependencies.
http://www.entropygames.net/index.php?option=com_contentview=articleid=52
I don't know the OSG code enough in detail to
I agree that my proposed fix is limited to s_renderBinPrototypeList, and
similar problems from other static objects can surface at a later time.
However, I fear that I can prove difficult to create an elegant infrastructure
for ordering the construction of static objects in a bullet-proof way.
It appears that others are also experiencing RenderBinPrototypeList destruction
problems when building osg as a static lib:
http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2009-April/026550.html
--
Read this topic online here:
I have now debugged the problem a bit, and it does indeed manifest itself under
both Win32 debug and release builds. The root of the problem is that the static
s_renderBinPrototypeList object (osgUtil/RenderBin.cpp line 44) is being
created before the static s_ReferencedGlobalMutext object
Oooops Please disregard the suggestion in my previous posting. What I meant
to suggest was:
--
static RenderBinPrototypeList* renderBinPrototypeList()
{
osg::Referenced::getGlobalReferencedMutex();
static osg::ref_ptrRenderBinPrototypeList s_renderBinPrototypeList = new
, but this does not seem to make any difference.
Configuration:
OSG 2.8.1, built with static OSG and OT libs. on MS visual C++ 9/2008 SP1.
Thanks in advance,
Fredrik Orderud
Rctl3dApp.exe!OpenThreads::Mutex::lock() Line 111 + 0xc bytes C++
Rctl3dApp.exe!OpenThreads
7 matches
Mail list logo