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 13:23:25

On Tuesday 31 March 2015 09:14:30 Steven Watanabe wrote:
> AMDG
> 
> On 03/30/2015 04:54 PM, 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.
> > 
> > 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.
> 
> Both of these will tend to result in pointlessly
> duplicating ASIO.

Well, Boost.ASIO code is currently compiled into Boost.Log, so unless the user 
links statically the duplication already exists.

> I don't think that libraries should set
> configuration options for other libraries.

What if the default config of the other library is not suitable? The reason 
why I added config enforcement is because compiler-based TLS can prevent using 
Boost.Log in dynamically loaded (i.e. with dlopen()) libraries. So with 
default config Boost.Log binaries are inconsistent and not working in some 
cases.