On 2 July 2018 at 03:48, Gavin Lambert via Boost
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*