Boost logo

Boost :

Subject: Re: [boost] [Boost.Serialization] Crash in current master (1.68)
From: degski (degski_at_[hidden])
Date: 2018-07-02 03:26:32


On 2 July 2018 at 03:48, Gavin Lambert via Boost <boost_at_[hidden]>
wrote:

> On 30/06/2018 03:20, Robert Ramey wrote:
>
>> I didn't realize that this occurs (only on?) configurations which create
>> shared libraries which link against static boost. Mixing shared libraries
>> is a known cause of difficulties. It many cases it seems to work, but in
>> many cases it also leads to unfixable failures.
>>
>
> By general definition, if you have two shared libraries that internally
> statically link the "same" library, they must *completely hide* that
> internal usage. Exactly zero of the internal library's symbols are
> permitted to exist in the shared library's export list, and absolutely
> never can any of its types appear in the shared library's own API.
>
> This includes usage by inheritance or by convention (such as being
> streamable to a serialization archive via templated operators).
>
> Violation of that rule occurs frequently (because it's hard to enforce and
> most of the time goes unnoticed) but it is still an ironclad rule if you
> don't want weird and undefined behaviour.
>
> Templates are a frequent cause of issues since they're very leaky by
> nature, and highly susceptible to ODR issues.
>
>
> In the context of Boost.Serialization, this means that you can pass the
> serialized representations across shared library module boundaries but you
> cannot pass archives or the serializable objects themselves across those
> boundaries, unless both shared libraries also use Boost.Serialization
> itself as a shared library.
>
> In general the simplest thing to do is to either keep everything static or
> everything shared; mixing leads to headaches unless a great deal of care is
> taken.
>

This is very useful information, in any context, be it Boost or not.

degski

-- 
*"If something cannot go on forever, it will stop" - Herbert Stein*

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk