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.