Please do not make the mistake of assuming that qDebug, qWarning, qCritical and qFatal always log on standard error. That's absolutely not the case.
The actual destination varies depending on the Qt configuration and the targeting OS. Plus, 5.4 and then 5.11 introduced some behavioural changes. See here and here for discussions.
TL;DR:
On Qt >= 5.11
- If the process' stderr has a console attached, that's where the debug log will go.
- If you want to always log on stderr, set
QT_FORCE_STDERR_LOGGING to 1.
- In alternative, set
QT_ASSUME_STDERR_HAS_CONSOLE to 1. I suspect this one is meant to be used by a parent process that reads a child's stderr and shows it to the user somehow.
QT_LOGGING_TO_CONSOLE to 1 still works, but Qt will complain.
On Qt >= 5.4 and < 5.11
- If you want to always log on stderr, set the
QT_LOGGING_TO_CONSOLE environment variable to 1.
- If you do not want to log on stderr, the
QT_LOGGING_TO_CONSOLE environment variable to 0 (this will force logging through the native system logger).
- If the
QT_LOGGING_TO_CONSOLE environment variable is not set, then whether logging to the console or not depends on whether the application is running in a TTY (on UNIX) or whether there's a console window (on Windows).
On Qt < 5.4, the situation is more confusing.
- If Qt has been built with support for a specific logging framework (e.g. SLOG2, journald, Android log, etc.) then logging always goes to that framework
- Otherwise on UNIX it goes to stderr
- Otherwise on Windows OutputDebugString or stderr is used depending whether the app is a console app.
The problem with the pre-5.4 approach was that, f.i., under Unix IDEs would not capture an application's debug output if Qt had been built with journald support. That's because the output went to journald, not to the IDE. In 5.4 the approach has been made more flexible and uniform across OSes.
