Thanks for all the info, sorry to make you spend time rehashing this! For my own sanity, I'll try to summarize the technical problem: It looks like the troublesome functions are defined in headers [1], so ogre gets the definitions hardcoded if it pulls in the headers. Those functions are now statically included and may only be compatible with a specific version of boost threads.
Because of this, programs can break since ogre is no longer binary compatible after a binNMU that bumps boost. The currently implemented fix solution is to define a build depends to a specefic the version of boos. That prevents ogre from secretly becoming binary incompatible with a binNMU, but it doesn't prevent it from happening manually. For example, even if ogre depended on boost 1.47 explicitly, this bug would have happened when ogre was bumped to 1.48 manually. I think, technically, it seems the the libogre package name should therefore have an indication of what boost version it was compiled against since policy says that if a new version of a library is not binary compatible with previous versions, it must have a name change. libogre-1.9 might have to be libogre-1.9-b1.54, and then the next version when compiled against boost 1.55 will be libogre-1.9-b1.55. That is awkward, but it looks like the only way to ensure binary compatibility. Longer term, maybe someone should talk with ogre upstream and see what they think of this. Should ogre be doing anything differently as to not expose those boost functions without a compiler error that there is a mismatch? Maybe ogre is missing [2]: #include <boost/config/abi_prefix.hpp> or #include <boost/config.hpp> in [3]? or something with: http://www.boost.org/development/separate_compilation.html [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674633#31 [2] http://www.boost.org/doc/libs/1_55_0/boost/config/abi_prefix.hpp [3] http://anonscm.debian.org/gitweb/?p=pkg-games/ogre-1.9.git;a=blob;f=OgreMain/include/Threading/OgreThreadHeadersBoost.h;hb=HEAD -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org