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?
