boost log should allow setting BOOST_LOG_EVENT_USE_BOOST_CONDITION manually

[Mathias Gaunard]

boost.log uses a different event mechanism depending on the version of GCC, for users wishing to use from GCC 4.4 a version of log compiled with GCC 4.1, linking fails because they're set to use different event mechanisms.

This could be fixed by simply allowing the user to define himself BOOST_LOG_EVENT_USE_BOOST_CONDITION which should disable attempting to use semaphores.

[Mathias Gaunard]

Pull request here:

​https://github.com/boostorg/log/pull/6

[Andrey Semashev]

I don't want to make BOOST_LOG_EVENT_USE_BOOST_CONDITION a public macro. The long term plan is to remove event implementation from Boost.Log and move to Boost.Sync. Until that happens, I could use Boost.Atomic for atomic ops instead of __sync* intrinsics directly. I believe, lack of those intrinsics in gcc 4.1 is what makes the condition variable version to be selected?

BTW, ABI compatibility between different compilers is not guaranteed - not only because Boost.Log can contain different versions of the code (like in the case of event) but because this can be the case in other libraries.

[Mathias Gaunard]

GCC has had a stable ABI since 4.0. Since it has many versions, it is very common for libraries that are shipped in binary form to be linked against code that uses a different version of GCC. Boost.Log is the only Boost library with this issue as far as I know, and the fix is quite simple, so I don't see a good reason not to include it if it fixes real deployment problems in the industry.

Arguably a better fix would be to have a sane ABI that doesn't change depending on compiler version, but that's more work.

[Andrey Semashev]

Done in ​https://github.com/boostorg/log/commit/30e7f036316d20285f8cecea36ca6a8ac0190125. BOOST_LOG_EVENT_USE_BOOST_CONDITION is still a private macro, it should not be used by users.