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

Subject: [boost] [log] [asio] Conflicting default configs
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-03-30 18:54:22

Hi,

In Boost.Log I'm using Boost.ASIO to implement network-based syslog backend. 
Boost.ASIO is used in the compiled part of Boost.Log and, obviously, can be 
used in the user's code as well. By default Boost.ASIO is header-only, so we 
basically have a copy of Boost.ASIO in Boost.Log and another copy in the 
user's app.

In Boost.Log I have the option to enable compiler-based TLS at the library 
build stage (BOOST_LOG_USE_COMPILER_TLS macro), which is by default not 
enabled. In Boost.ASIO there is a similar option 
(BOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION macro) but the feature is enabled 
by default. I want Boost.Log built libraries to actually respect the 
BOOST_LOG_USE_COMPILER_TLS option, so I define 
BOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION internally when 
BOOST_LOG_USE_COMPILER_TLS is not defined.

The problem is that Boost.ASIO changes implementation in an incompatible way 
when BOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION is defined. It is further 
worsened by a recent change that makes all of Boost.ASIO symbols externally 
visible. Basically, this means hard to debug trouble on user's end, when 
different versions of Boost.ASIO (one from Boost.Log binaries and the other 
used by the user's code directly) are used at the same time.

I'd like to ask community what is the preferred resolution of this situation 
(and possibly similar ones in the future). I can see several ways of tackling 
this:

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.

3. Change the defaults, either in Boost.Log or in Boost.ASIO, so that they are 
aligned by default. When the user changes Boost.Log config he would be 
expected to know that Boost.ASIO config also needs to be changed accordingly. 
If he doesn't, Boost.Log is still built consistently with its own config. 
Note, however, that since Boost.Log is a built library and in most 
distributions it is built with default options, the choice for Boost.Log is 
more significant and because of that should probably be more conservative.

4. Same as 3 but also remove the enforcement of Boost.ASIO config by 
Boost.Log. Whenever the user wants to change the default, he would have to 
define macros for the both libraries, otherwise Boost.Log can be built 
inconsistently.

5. Do not change the defaults but remove the config enforcement. 
BOOST_LOG_USE_COMPILER_TLS becomes Boost.Log-local and as such does not 
guarantee that the resulting binaries do not in fact use compiler-based TLS. 
Users can get surprised.

6. Do not change anything, let the users suffer because of ODR issues. Maybe 
document this somewhere...

Opinions?