spdlog icon indicating copy to clipboard operation
spdlog copied to clipboard

inline registry leads to split instances across .so borders

Open kikaxa opened this issue 1 year ago • 5 comments

SPDLOG_INLINE registry &registry::instance() returns local instance in each so, preventing configuration and central reuse of logger.

sample naive configuration, with most(all?) default spdlog build/use possibilities not achieving expectations: +main exe +shared/reused common libs(static/dynamic) +multiple plugins .so all using (expected to be same?) logger

kikaxa avatar Feb 08 '24 13:02 kikaxa

Since &registry::instance() is an internal API, the application should not call it directly.

tt4g avatar Feb 08 '24 21:02 tt4g

Of course. It is the central instance that is used by everything else, including configuration, sinks and logging itself.

kikaxa avatar Feb 09 '24 09:02 kikaxa

Is it correct that the question is about the handling of the spdlog registry when using the public API?

To give some historical background, spdlog was initially a header-only library. It was not until version 1.4.0 that it became buildable as a shared/static library: https://github.com/gabime/spdlog/releases/tag/v1.4.0

In header-only spdlog, it was left to the developer to decide whether the memory managing the spdlog global registry should be the library's or the application's.

If you want to share the registry with spdlog built as a library, please see the Wiki. However, the same instance of the spdlog registry built as a shared library on Linux is always shared.

There is probably no way to avoid sharing the spdlog registry between libraries and applications. The easiest solution would be to not use the spdlog registry. Libraries and applications should provide their own APIs to replace the spdlog registry.

tt4g avatar Feb 09 '24 10:02 tt4g

Thank you. This document is spot-on, but not easily discoverable through md, headers or cmake. The shared library would have a tradeoffs in performance, i think? Still, using shared in the modular program would similarly result in plugins having its own local copy of spdlog.so=registry used

Libraries and applications should provide their own APIs to replace the spdlog registry.

How do you imagine that implemented? Do not see any documented or straight-forward ways to do that..? I would expect there to be a way to say "i want to use whatever else everyone uses".

I tried overriding # define SPDLOG_INLINE inline __attribute__ ((weak)) which achieves exactly what is expected(with some caveats as usual).

kikaxa avatar Feb 09 '24 12:02 kikaxa

fwiw we are thinking about ways to improve this in v2.x branch. Perhaps by adding a function to set/get the registry instance, so that dlls can be provided a registry object from the main exe, which in turn they can set as current registry.

gabime avatar Feb 09 '24 12:02 gabime