Open Lord-Kamina opened 1 day ago
The STDOUT/STDERR handle got by stdout_color_sink is considered invalid.
You should not call AttachConsole()
or AllocConsole()
at least after stdout_color_sink.
The STDOUT/STDERR handle got by stdout_color_sink is considered invalid.
You should not call
AttachConsole()
orAllocConsole()
at least after stdout_color_sink.
If I don't call those functions there's still no output from spdlog, but then there's also no output from std::clog
either.
Maybe I need to use SetStdHandle
as well?
Maybe I need to use
SetStdHandle
as well?
As far as the official documentation is concerned, yes: https://learn.microsoft.com/en-us/windows/console/console-handles This is not a spdlog question, so I suggest you ask it in the Microsoft Community or on StackOverflow.
I posted it here because it's only speedlog that's not working but it probably has to do with orders of initialization so thanks for that.
And, do you have any idea what could be going on with the log formatting not working on windows?
And, do you have any idea what could be going on with the log formatting not working on windows?
Are you talking about color by ANSI escape sequences? Windows is not supported: #3103 #3111
And, do you have any idea what could be going on with the log formatting not working on windows?
Are you talking about color by ANSI escape sequences? Windows is not supported: #3103 #3111
No. On windows I am planning to use the windows console color api (that's what all the nasty defines are about) but that's not the question. The problem is spdlog is not applying my custom format string to messages written to the logfile.
Here's where I'm at:
I managed to fix the issue of there not being any output at all to the console by moving the 'AttachConsole'/'AllocConsole' calls to another class that is initialized pretty much first thing when going into main (and before any spdlog calls), and now spdlog is indeed producing output to the console as expected. I don't have color but I'm hoping that will be fixed when I revert manually setting the color_mode
to never
.
However, when I write to the logfile on windows, spdlog is not using my custom pattern for the log message ("[%T]:::%^%n / %l%$::: %v"
) but instead it's using the default spdlog format, what would be equivalent to %+
, even though logs to the console are using the expected pattern, and even though I tried manually changing the pattern on both the logger itself as well as the sink.
P.S. This is a behavior I'm only seeing on Windows so far.
The problem is spdlog is not applying my custom format string to messages written to the logfile.
Not a console?
I thought it was expected behavior that the format defaults to file since you didn't call file_sink->set_pattern()
.
I continue in my efforts to convert our old logger over to spdlog, and for the most part have been successful. Currently, on my mac the app is producing both a logfile and colored output to the console as I expect it to.
However, I decided to run some tests in windows, because I also wanted to try some code that was before just disabled on windows builds. After much trial and error, it should be working but alas, I get no output on the console.
Let me first walk you through the relevant parts of my code...
I have a SpdLogger class, that constructs and configures the various loggers. You'll noticed there's an odd loop where several loggers are created, what that does is iterate over an enum containing all valid logger names, construct each of them and register them with spdlog, as well as in an unordered_map I can use to look the pointers up without blocking the spdlog registry.
Then there's the
StdErrGreabber
struct, which essentially captures output to stderr, and formats and redirects it to stdout.The
getLogger
function is called in the variousSpdLogger::debug/trace/etc
functions.The writeHeader function is using its own special logger to prevent duplicate output.
On macOS, I am getting:
"[%T]:::%^%n / %l%$::: %v"
On windows, I am getting:
Below are the relevant code snippets. P.S. I tried turning off color because I read an old issue saying using color on windows could cause output to be lost, but it didn't really make any difference.