-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
inline registry leads to split instances across .so borders #3003
Comments
Since |
Of course. It is the central instance that is used by everything else, including configuration, sinks and logging itself. |
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. 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. There is probably no way to avoid sharing the spdlog registry between libraries and applications. |
Thank you.
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 |
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. |
SPDLOG_INLINE registry ®istry::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
The text was updated successfully, but these errors were encountered: