Re: [boost] [Boost.Serialization] Crash in current master (1.68)

Subject: Re: [boost] [Boost.Serialization] Crash in current master (1.68)
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2018-07-02 00:48:37

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.