Hi there,
from what I can see, boost::shared_ptr has a different definition,
depending on whether Boost is compiled in C++98 oder C++11 mode. For
example, in C++11-mode, shared_ptr has a move-constructor. By default,
however, Boost seems to be compiled in C++98 mode, even with a compiler
like gcc 4.8 (Ubuntu 13.10 / 64 bit / Boost 1.55), that is perfectly
capable of compiling in C++11 mode. So, while boost::shared_ptr is
header-only, all Boost libraries that use boost::shared_ptr will assume
the C++98 version.
The build-environment of one of my applications checks the compiler
(currently gcc and CLang) and, depending on the version, activates C++11
support, so that I can use some C++11-checks (such as override), that
can easily be #defined away for C++98 .
So what may happen here is that my main application uses a different
boost::shared_ptr than the Boost libraries I want to link with. To me
this seems to violate the one-definition rule (and may happen with other
Boost libraries as well).
Indeed I'm seeing some strange errors, where "if(!p) {raise_error();}"
triggers for a shared_ptr