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.