Re: Bug#384565: [Monotone-devel] Re: Bug#384565: monotone - FTBFS: Build killed with signal 15

[Nathaniel Smith]

On Wed, Nov 22, 2006 at 09:54:42AM -0700, Shaun Jackman wrote:
> On 11/22/06, Roman Zippel <address@hidden> wrote:
> ...
> >> 1. Is this more likely a bug in Boost or a bug in monotone?
> >> 2. Is it reasonable to workaround this bug by removing
> >> -DBOOST_SP_DISABLE_THREADS?
> >> 3. Is it worth going to the extra effort to only define
> >> -DBOOST_SP_DISABLE_THREADS on the platforms for which it works? I'll
> >> consider this last option if it means a performance improvement of at
> >> least, say arbitrarily, a factor of two or so.
> >
> >I think this should include the boost maintainer, there has to be some way
> >to safely select the proper compile flags. At least the Debian packages
> >provide a threaded and non-threaded version, but the .so link points to
> >the threaded version by default.
> >If both versions are supposed to be usable equally for non-threaded
> >application it suggest a bug in boost...
> >Anyway, until there is some mechanism to select this safely, it's probably
> >better to compile the application with the same flags as the library was.

Right -- I tracked down the official word on this, which says:

"If your program is single-threaded and does not link to any
libraries that might have used shared_ptr in its default
configuration, you can #define the macro BOOST_SP_DISABLE_THREADS on a
project-wide basis to switch to ordinary non-atomic reference count
updates.

"(Defining BOOST_SP_DISABLE_THREADS in some, but not all, translation
units is technically a violation of the One Definition Rule and
undefined behavior. Nevertheless, the implementation attempts to do
its best to accommodate the request to use non-atomic updates in those
translation units. No guarantees, though.)"
  ( http://www.boost.org/libs/smart_ptr/shared_ptr.htm )

So basically, if a program uses boost::shared_ptr, and also uses
libraries that use boost::shared_ptr (including other boost
libraries), then your program and those libraries must be compiled
with the same BOOST_SP_DISABLE_THREADS setting.  Unless you get lucky.
(I guess it failing on less popular platforms in particular has
something to do with the workarounds they mention in the second
paragraph?)

> I'll probably make an upload today. So, to be sure, I'm going to
> remove -DBOOST_SP_DISABLE_THREADS, but leave -DBOOST_DISABLE_THREADS?
> Is that correct, or are both defines to be removed?

That sounds correct.  I suspect the reason _SP_ is split off as its
own thing is exactly this...

-- Nathaniel

-- 
"The problem...is that sets have a very limited range of
activities -- they can't carry pianos, for example, nor drink
beer."