spdlog as shared library, global log registration.

[rioki]

I am using spdlog via vcpkg on Windows. I was a bit confused when the set_default_logger did not apply over the library boundary. The documentation mentions the header only version of sdllog and a workaround; but this applies also to the shared library version.

Even if I explicitly set SPDLOG_COMPILED_LIB and SPDLOG_SHARED_LIB I get the behavior. It appears that default_logger_raw and details::registry::instance() always get inlined no matter what.

I am not sure, but this seems to be a deliberate choice to ensure compatibility to the header only version. Although I find that rather annoying I have a workaround; I wrote macros that wrap spdlog anyway so that I can capture the location and then I just added my own global reference that I can read and write via function in the DLL.

Is this behavior intentional? Is this a bug? or am I just incompetent to build and link against spdlog properly?

[tt4g]

This is due to the spdlog design and the C++ language specification.
spdlog was previously header-only library, but with version 1.4.0, static library and shared library build support has been added.

Since support for the header-only library is still in place, spdlog keeps default loggers and logger registry in variables with the static keyword in order to manage the global state.

And in the C++ language specification, static variables are placed in dedicated memory storage on a per-build basis (libraries, executables).

With this specification, the default logger variables accessed when spdlog is built as a shared library and the default logger variables accessed by applications linked with spdlog (shared library) refer to different memory.

The way to access the default logger in the shared library from your application (as you have done) is to have a published function in the shared library that accesses the default logger.
This is because when accessed from code in the shared library, it accesses the default logger variables that are placed in the shared library's memory storage.

See also:

• https://stackoverflow.com/questions/19373061/what-happens-to-global-and-static-variables-in-a-shared-library-when-it-is-dynam
• https://stackoverflow.com/questions/93039/where-are-static-variables-stored-in-c-and-c
• why not shared registry between main and shared library??? #2033 (comment)

[rioki]

Thank you for the explanation, I missed the static bit. I am fully aware that you can't/shouldn't just change the behavior; but I don't understand the rationale, especially given in #2033 . I understand the technical bits, not the why?

The security comment makes no sense at all. If multiple applications load a shared library each gets it's own memory space. I know no OS where two applications share memory space for shared libraries¹.

That being said, if two libraries both use spdlog and set the default logger, the current design means they each have their own version. But I don't know if that is actually the behavior spdlog's API and design suggest. That is the thing thing with global state, if a library has a good reason to mess with global state it dawn well should be able to do so. The nice thing about spdlog is that you don't need to use the default logger and can just spin up your own and then use that for special contexts.

A quite common usage pattern, as seen in the DLL example, is to create and set a default logger in the main function and libraries just use the global log functions. I cam very well imagine a DLL advertising it's using spdlog and when you can just set it's logger through the set_default_logger function. After all in most settings you tend to want to have one logfile for the entire application.

¹ Ignoring ReadProcessMemory and similar functions here, this is not normal operations for C++.

[tt4g]

To help you understand, I will also explain the detailed internal implementation.

In spdlog, the spdlog::details::registory object is used to manage default loggers and so on.
We can access the singleton object calling spdlog::details::registory::instance(), in this function static registry s_instance; is declared and initialized.

spdlog/include/spdlog/details/registry-inl.h

Lines 291 to 295 in eb32206

	SPDLOG_INLINE registry &registry::instance()
	{
	static registry s_instance;
	return s_instance;
	}

The important thing here is that the extern keyword is not given.
On Windows OS, a static variable without the extern keyword is not a global variable. They are placed in their own memory storage in translation units (compilation units).
If any static variable (is declared in a function) that we want to expose from the library, we need to go through a function with the __declspec(dllexport) keyword.

However, spdlog::details::registry is internal class, and __declspec(dllexport) is not given.
Thus, when you call spdlog::* static function from the library, a library-specific spdlog::details::registry object will be placed, and when you call spdlog::* static variable from the application, an application-specific spdlog::details::registry object will be placed.

See also: See: https://stackoverflow.com/a/2479944

[rioki]

I understand the issue; it's because of inlining, the registry variable will be inlined into each module. But why did you chose to go this route for the shared library version?

One line of code would change the behavior to be globally accessible. I mean I basically mimicked the set_default_logger() / default_logger_raw() functions in my project.

So far I can not wrap my head around why this design decision is a good idea?

[tt4g]

In version 0.9.0 (the first official release: https://github.com/gabime/spdlog/releases/tag/v0.9.0), the spdlog::details::registerry::instance() function is present.

spdlog/include/spdlog/details/registry.h

Lines 132 to 136 in 36ba06a

	static registry_t<Mutex>& instance()
	{
	static registry_t<Mutex> s_instance;
	return s_instance;
	}

I don't know if there was enough discussion about it at the time, but I don't think it would have been a problem with a header-only library.

[rioki]

I see... I would be unwise to change the behavior now...

[gabime]

One line of code would change the behavior to be globally accessible

Which single line of code would fix this? (need to work on windows&linux and in shared/static/header-only configurations)

[rioki]

From the rather terse comment I sense some irritation, I apologies for having created some. I appears I am not stating my point sufficiently cleanly as tt4g already very painstakingly explained the obvious to me.

As I already stated in my very fist point, this feels like a very deliberate design decision; which I can whole heatedly understand. It seems to me that the current limitations in the shared library version exist to match the behavior of the header only library.

I don't think we need consider differences in Windows and POSIX libraries, as once you hit the C++ level of abstraction, they behave generally the same.

The limitation of the header only and static library is, well a limitation and once you have a shared library you can remedy this. spdlog is not the only library that is in this position, where you may get differing behavior based on what kind of linking strategy you chose.

What I would like to see and would also implement, is the ability to opt in via macro for the registry to be local to the spdlog shared library and as a result available to the entire application. The nice thing is that it is entire optional, even within one application. As the inline version creates a local instance and the static statement within the instance function is not exposed in the ABI and this does not create a link conflict. Although I would strongly advise against such a plan of action.

If you believe consistency is more important than utility, I commend you as you would be ahead of many a open source project.

[gabime]

From the rather terse comment I sense some irritation, I apologies for having created some..

No problem, its all good. I am really trying to understand how this can be fixed in a single line of code. Would be very helpful (regardless the question of of backward compatibility).

[rioki]

See PR2200.

[rioki]

I must apologize to have wasted your time.

"or am I just incompetent to build and link against spdlog properly?" applies here.

If you link against the shared library version you need to ensure that both SPDLOG_COMPILED_LIB and SPDLOG_SHARED_LIB are set before any spdlog header is accessed. Then and only then does it actually link in the important bits that are inlined in the header only bit.