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).