Re: [boost] [log] [asio] Conflicting default configs

Subject: Re: [boost] [log] [asio] Conflicting default configs
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-03-31 04:32:52

On Tuesday 31 March 2015 01:41:56 Niall Douglas wrote:
> On 31 Mar 2015 at 1:54, Andrey Semashev wrote:
> > 1. Introduce an inline ABI namespace in Boost.ASIO, much like the one I
> > have in Boost.Log. The namespace name would depend on
> > BOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION and other macros that affect
> > binary compatibility. This would be my preferred solution, although I'm
> > not
> > sure how fast and easy it can be implemented.
> 
> Why don't you just use standalone ASIO internally? It has a different
> ABI, and I believe is expected to not interact with Boost.ASIO.

That would be an external dependency, which may not be present at build time. 
And it doesn't fundamentally fix the problem - it would still cause trouble if 
the user uses a differently configured standalone ASIO.

> The internal copy can be generated using Chris's special "include all
> of ASIO" magic file. Just fire it through a bit of python which
> implements only the #include directive or use a STL excluding
> preprocessor to generate a single file including all of standalone
> ASIO.

Oh, you mean to basically copy&paste ASIO into Boost.Log under some different 
namespace? I guess that's possible, although I don't need that much of ASIO 
and that would certainly be a bloat. It might be better to remove Boost.ASIO 
and use native API directly. I would like to avoid this approach if another is 
possible.

> > 2. Remove symbol visibility enforcement from Boost.ASIO, or at least make
> > it optional. That way I could encapsulate my private copy of Boost.ASIO
> > in Boost.Log binaries.
> 
> You'd still run into ABI mismatch if the end user uses a different
> Boost ASIO version to you which is not uncommon (users like to pin
> the version of Boost and Boost.ASIO separately). The only valid
> visibility of an internal ASIO is hidden, but then you have to be
> real careful you never allow Log to be used as anything but a shared
> object else you'll cause all ASIOs to be hidden too as hidden
> visibility is sticky.

If different Boost.ASIO versions (or different configurations of Boost.ASIO) 
are used and Boost.Log is a static lib then yes, that option wouldn't help. 
Actually, I'm not sure if different releases of Boost.ASIO are workable at all 
in this setup. I guess, the solution in this case should involve name mangling 
(e.g. the internal namespace).