提升日志和动态加载的库

如何解决提升日志和动态加载的库

我们在应用程序中使用Boost.Log v2（1.70），该应用程序可用于Windows和Linux。最近，我将动态加载的dll重构为也使用Boost.Log。

dll导出C api函数以访问专用硬件。它可用于各种编程环境：C，C ++，Python，Delphi和Labview。 （其中大多数不使用Boost.Log）。

对于Windows，该dll被构建为仅使用静态库并使用静态运行时，从而使部署更加容易。

这按预期工作：两个增强日志实例似乎完全相互独立。 该应用程序登录到其文件接收器，dll登录到另一个。

在Linux上，该插件被构建为使用共享的运行时库和共享的boost库。我们故意这样做是为了能够使用Linux发行版Boost库。

效果是，插件加载后，应用程序不再登录到其接收器。我们正在从插件中看到日志。 由于api dll不知道可能还有其他人也在使用Boost.Log（==相同实例），因此它会在记录日志重新配置时调用boost :: log :: core :: get（）-> remove_all_sinks（）。>

是否有可能走类似的路线（例如Windows）并尝试使用静态链接和静态运行时来构建插件？

还是这种方法注定要失败？

虽然目前可以使用，但是正在使用静态运行时+静态链接Boost.Log记录适用于Windows的可行构建配置吗？

预先感谢， 冈瑟

解决方法

在多个模块（可执行和/或共享库）中使用Boost.Log的静态库是not supported，将无法正常使用。 Boost.Log在内部维护多个单例，这在一个进程中具有多个Boost.Log实例而被破坏。

,

谢谢Andrey Semashev和Ulrich Eckhardt。

我现在了解到Boost.Log的库实现会限制其使用。

无效用法：应用程序使用dlopen（Linux）或LoadLibrary（Windows）链接增强日志（作为dll）并动态加载另一个api.dll（通过静态链接静态链接以增强静态静态运行时的日志）。 ）是不确定的行为。它可能有效，但可能无效。

有效用法：：如果两个人工制品（应用程序，api.dll）共享Boost.Log（通过dll，共享运行时），则他们必须意识到这一点，以便记录一个人工制品的配置不会被另一个更改或删除。从技术角度来看，这仍然是一个有效的用例。

将来，我们将不再在api.dll中使用Boost.log来删除这种情况下的未定义行为。

@Ulrich Eckhard：Api.dll的接口仅是C。这是必需的，因为Api用于各种环境（C，C ++，Python，Labview等）。这就是为什么api.dll带有其自己完整的日志记录基础结构的原因。没有公开的类-在这种情况下，依赖倒置不是可行的解决方案。

谢谢

Gunther