Should Boost.Log work with a sink in a dynamically linked application and logging source in a DLL loaded via LoadLibrary?

Question

I maintain a Qt application that makes extensive use of plugins, and am trying to streamline the logging behavior by moving to Boost.Log.

The simplified structure is as follows:

MainLibrary.dll: has the bulk of the code, including the parent class for all the plugins and the primary logging sink (currently a basic file_log).

Application.exe: thin layer on top of MainLibrary.dll, mostly UI stuff, compiled with dynamic linking

Plugin.dll: A plugin, using the QPluginLoader system which internally uses LoadLibrary. Ideally each plugin would have its own source (defined in the parent class in MainLibrary.dll), but at a minimum I'd like to be able to use the named_scope attribute to log location in the plugin. Both approaches are behaving unexpectedly.

Basic logging worked as expected when used within MainLibrary.dll, so I'm confident that I'm instantiating everything correctly for normal operation.

Based on this question, my understanding was that so long as all the code involved was dynamically linked, the Boost.Log singletons would work as intended even with LoadLibrary and the library would behave normally.

Per this question, I have confirmed that my boost libraries are compiled with dynamic linking.

When I tried creating a logging source for each plugin by making it a member of the parent class in MainLibrary.dll, then log entries created in Plugin.dll go to the default sink (stdout) but never reach the file_log defined in MainLibrary.dll.

I then tried creating a thread-safe global logger using BOOST_LOG_INLINE_GLOBAL_LOGGER_DEFAULT in MainLibrary.dll. Plugin.dll is able to write with the global logger, but it is also sinked to the default sink (stdout) rather than the file_log in MainLibrary.dll.

I am aware of several ways to get the information I want into the log (albeit in most cases as part of the message rather than as a proper attribute), so I'm not looking for solve-the-immediate-problem solutions. My questions are:

1. Is the behavior of Boost.Log with LoadLibrary when both the executable and the loaded library are dynamically linked defined, and is this expected behavior?
2. Assuming it's important that all the plugins dump to the same sink (rather than a sink for each plugin), is there a different, correct paradigm for this I'm missing?