Ringbuffer sink keeps user-given number of most recent log messages in
memory and returns them upon request (using the ringbuffer_sink::last
method). This can be useful for e.g. remote debugging of a running app.
The meaning of using quotes to #include is implementation defined, so it
may or not may be what we want. At least POSIX
(https://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html)
says: "headers whose names are enclosed in double-quotes ( "" ) shall be
searched for first in the directory of the file with the #include line",
so not what we want since "spdlog" ends up twice in the path.
`__cplusplus_winrt` only detected C++/CX (which can be used without compiling for UWP, SetHandleInformation would be available in those cases), and did not detect native UWP C++. This patch fixes that by using the WINAPI_FAMILY_PARTITION macro in the Windows SDK headers in the same way those headers remove SetHandleInformation in UWP builds.
Previously, the logger name was effectively lost. There were two choices
on how to add it:
- Via a formatter, which would mean that `journalctl` would not be able
to filter against that. That would be suboptimal.
- As a "syslog identifier". This means that `journalctl` will, by
default, stop showing the daemon's executable name and replace that via
the logger name. The PID is still shown, and if one would like to go
back to the previous behavior, it is still possible via `journalctl -o
with-unit`.
I think that the second option is strictly better than the first one.
fixes#1289
This is what my manpage says, and what the original blog post [1] says
as well.
Also, `sd_journal_send` can add the location of its own invocation to
the log. That's typically not what we want, so we have to suppress that
feature and instead put whatever is inside the spdlog message into the
journal.
[1] http://0pointer.de/blog/projects/journal-submit.html
When cross-compiling spdlog from x86-64 to armhf, I ran spdlog-utests
via qemu-arm and noticed that the "daily_logger rotate" test was failing
because count_files always returned zero.
Investigation of count_files revealed that readdir was returning nullptr
immediately and setting errno to 75, i.e. "value too large for defined
data type". I suspected this had something to do with some 64 vs.
32-bit thing, so I added _FILE_OFFSET_BITS=64 to the build and that
seems to have made readdir happy.
It might be safe to add _FILE_OFFSET_BITS=64 for all Linux builds, but
it only seems to be necessary for the 32-bit case (which is a pretty
small audience these days -- I'm only building for armhf to target a
Raspberry Pi 3 running Raspbian, which runs in 32-bit mode).
