Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.
Some of the addon libs (for example Caelum) don't work since trunk revision 8787 (8786 is working fine). I have trouble debugging on my linux system but here is a call stack:
I had a feeling that there might be some fallout from all the changes I made, especially regarding uninitialized variables. I'm going to check in a patch that has a chance of fixing it. I've never used Caelum so let me know if you still have trouble.
Neither OgrePrefabFactory.cpp or OgreSharedPtr.h changed in revision 8787 though. Uninitialised vars fixes looked fine to me, and I haven't had any issues so far.
The interesting thing is that SharedPtr is not being used in those lines in PrefabFactory, it's a raw Mesh*. Therefore there's no reason at all for it to be in OgreSharedPtr.h. I'm betting on an unclean build or a failure to install new binaries correctly.
I just uninstalled and deleted both my ogre and caelum directories, checked out latest ogre and caelum svn and rebuild everything. I'm 100% sure there are no remains from a previous build left on my system (linux x64).
What I'm not so sure about is the stack trace I posted above, it from my own project, not from the Caelum demo itself. Probably you guys should just ignore it when debugging this. The caelum problem is actually pretty easy to reproduce, just get caelum svn from https://caelum.svn.sf.net/svnroot/caelum/trunk/Caelum and build the library
We (or rather: I) had some issues with Ogre::FileInfoListPtr corrupting memory after updating from rev. 8786 to HEAD.
Not really sure what the problem is as I didn't look hard into it. Reverted to last know good 8786.
/* Less noise. More signal. */ Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion. OgreAddons - the Ogre code suppository.
-# Read contents of the OgreConfig.h file
-file(READ "${OGRE_SOURCE_DIR}/OgreMain/include/OgreConfig.h" OGRE_CONFIG_H)
-# add HAVE_OGRE_BUILDSETTINGS_H preprocessor define
-file(WRITE ${OGRE_BINARY_DIR}/include/OgreConfig.h "#define HAVE_OGRE_BUILDSETTINGS_H\n${OGRE_CONFIG_H}")
-install(FILES ${OGRE_BINARY_DIR}/include/OgreConfig.h DESTINATION include/OGRE)
+# Install OgreConfig.h file
+# This used to add HAVE_OGRE_BUILDSETTINGS_H to the top, which is a duplicate of adding -DHAVE_OGRE_BUILDSETTINGS_H
+install(FILES ${OGRE_SOURCE_DIR}/OgreMain/include/OgreConfig.h DESTINATION include/OGRE)
Writing a new OgreConfig.h is not redundant because when building stuff from the outside HAVE_OGRE_BUILDSETTINGS_H might not be defined. It's certainly not defined on Linux via pkg-config.
I my guess is that this causes Ogre to be build with THREAD_SUPPORT=2 and a mutex in each SharedPtr; while external stuff is built with THREAD_SUPPORT=0 and a smaller SharedPtr. This results in memory corruption.
Reverting those lines makes this work for me; and is probably better than making sure everybody has HAVE_OGRE_BUILDSETTINGS_H defined. It's doable on linux with pkg-config; but very confusing for windows users.