Boost log and dynamically loaded libraries

Question

We are using Boost.Log v2 (1.70) in our application which is available for Windows and Linux. Recently I refactored a dynamically loaded dll to also use Boost.Log.

The dll exports C api functions to access dedicated hardware. It is used in various programming environments: C, C++, Python, Delphi and also Labview. (Most of them not using Boost.Log).

For Windows the dll is build to only use static libaries and to use a static runtime, making deployment much easier.

This works as expected: Both boost log instances seem to be fully independent of each other. The app logs into its file sink, the dll into another one.

On Linux the plugin is build to use shared runtime and shared boost libraries. We made this intentionally to be able to use the Linux distributions boost libraries.

The effect is that after plugin load the application no longer logs into its sink. We are seeing logs from the plugin instead. As the api dll is not aware that there may be others also using Boost.Log (== the same instance), it calls boost::log::core::get()-> remove_all_sinks() on logging reconfigurations.

Would it be possible to go a similar route (like in Windows) and to try to build the plugin using static linking and a static runtime?

Or is this approach doomed?

Though currently working, is using a static runtime + static linking Boost.Log a viable build configuration for Windows?

Thanks in advance, Gunther

Answer 1

Thank you Andrey Semashev and Ulrich Eckhardt.

I now understand that the library implementation of Boost.Log restricts its usage.

Invalid usage: A application links boost log (as dll) and dynamically loads another api.dll (linked statically to boost log static with static runtime) by using dlopen(Linux) or LoadLibrary(Windows) is undefined behaviour. It may work, it may not.

Valid usage: If both artefacts (app, api.dll) share Boost.Log (by dll, shared runtime), they have to be aware of it, so that logging configuration of one artefact will not get changed or deleted by the other one. Still from the technical point of view this would be a valid use case.

In the future we will no longer use Boost.log in the api.dll removing the undefined behaviour in this case.

@Ulrich Eckhard: The interface to the Api.dll is C only. This is needed as the Api is used in various envrionments (C, C++, Python, Labview, ...). Thats why the api.dll comes with its own complete logging infrastructure. There are no classes exposed - dependency inversion is not a viable solution in this case.

Thank you,

Gunther

Answer 2

Using static library of Boost.Log in multiple modules (executable and/or shared libraries) is not supported and will not work as intended. Boost.Log maintains a number of singletons internally, which is broken by having multiple instances of Boost.Log in a process.