Bug#749944: build ogre-1.9 against new boost-defaults 1.55?

[Manuel A. Fernandez Montecelo]

2014-05-31 16:30 GMT+01:00 Scott Howard <showard314 at gmail.com>:
> 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.

Yes, I believe that the above, with two comments:

- I don't know if the problem was supposed to be a bug in Boost that
it's not likely to occur again until next century, or if OGRE or
something else are doing something wrong in using Boost.  The fact
that it did not repeat in a few years (and could have been repeated
now with the binNMU of ogre-1.8) seems to indicate that it's not very
frequent, at least.

- probably you meant this already, but it's not OGRE that it becomes
incompatible with itself -- the incompatibility is in the projects
that use OGRE


> 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.

Maybe it's the only solution, but ugh, it's ugly and complicated/has
many disadvantages (frequently having to go through NEW queue several
times per year, transitions needed, etc).  In that case I wonder if
it's better to risk occasional problems!

Specially since the solution was devised as a somehow quick fix before
a freeze, and because I didn't know if the problem would recur in the
future soon after that -- but it seems that it didn't, in a few years.

If now the drawbacks are worse than just depending on the default
Boost versions, maybe we can just do that.


> 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

I don't know if I mention this to them in the past.  It happened in a
time when development was not very active and the old leader had to
retire for some reason, I think.

Since then, I submitted bugs that they fixed like inclusion of 3rd
party library code, co-installability of different versions, support
for new ports, etc.

I will forward this to them hopefully soonish (but not now).  If
somebody beats me to it, I will not complain! :-)


Cheers and thanks for your help.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>