Hi Manuel,
I understand that how the package is presently set up is the standard
way to go about things, and I certainly wouldn't want to cause a bunch
of issues by having that changed. However, I believe the potential for
issues is very real - mostly because I experienced them, and spent a few
hours tracking them down. At that time, I had the 1.48 libboost-*dev
packages as the 1.49 versions were being held back by apt-get. I
manually removed the 1.48 versions to allow the 1.49 packages to be
installed, and after rebuilding the code I was working on, the issue I
had went away.
For info, I'm the lead developer on the CEGUI library, and the issue I
had was while working on the Ogre module for CEGUI. Obviously CEGUI is
a lot of code to suggest someone get to try and reproduce an issue, so
I've tried to create some code for a basic test case - though I
additionally acknowledge this may be quite hard to test because it
basically requires downgrading the libboost-*dev packages to 1.48.
// save this as main.cpp (the code tries to load a file named main.cpp)
#include <OGRE/OgreRoot.h>
#include <OGRE/OgreDataStream.h>
#include <iostream>
int main(int argc, char** argv)
{
new Ogre::Root;
Ogre::ResourceGroupManager&
rgm(Ogre::ResourceGroupManager::getSingleton());
rgm.createResourceGroup("test");
rgm.addResourceLocation(".", "FileSystem", "test");
{
Ogre::DataStreamPtr dsp = rgm.openResource("main.cpp", "test");
}
std::cout << "Exiting cleanly..." << std::endl;
return 0;
}
I built this code with:
$ g++ main.cpp -g -O -lOgreMain
Basically, if the libboost-*dev packages are 1.48 and Ogre is built
against 1.49, the executable produced will hang in mutex code related
to the use of boost threads. If the installed libboost-*dev packages
match those used to build Ogre, the executable will display the message
and exit cleanly.
Another scenario I thought of (but did not experience directly) is if
a developer has code that uses boost-threads directly as well as
using Ogre. Here it would be natural for the developer to link their
code to libboost_thread and libOgreMain. If the libboost-thread-dev
is, say, version 1.48, and libOgreMain - as you correctly pointed out -
has references to the 1.49 version of libboost_thread, the executable
would bring in two versions of the same lib (a linker warning is
produced announcing the possible conflict). A developer could skip
directly linking libboost_thread and implicitly pick up the version
referenced by libOgreMain, but then they have the situation of having
compiled against the 1.48 headers but have the 1.49 library (which may
or may not be harmless, depending on whether ABI compatibility between
the two library versions was maintained - a rarity when dealing with
boost, I think).
I should probably add that, in my opinion, the potential for issues to
occur is highly unlikely to be limited to Ogre. I'm really not certain
what the best thing, or the right thing to do in this situation is.
All I can say is that the issues that can occur are indeed very real,
though probably would only ever affect a minority of users and only
when specific circumstances exist.
Regardless of what, if any, action is taken, I hope this helps to
explain the situation a little better. It may also help someone in the
future if they're unfortunate enough to experience similar things, and
at the very least it gives me somewhere to point to if CEGUI users
report this as a bug in CEGUI ;)
Kindest regards,
Paul.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
