A common usecase for Libreoffice writer is to act as a headless rendering component. While the UNO API can be used, the command line options like --convert-to seem to offer a much lower barrier to entry. Unfortunately; things like #37531 crop up. Examples of confused users: http://stackoverflow.com/questions/22062973/libreoffice-convert-to-not-working * Silent 'failure', users only figuring out they haven't installed libreoffice-writer by accident, etc. http://stackoverflow.com/questions/24704536/how-do-i-convert-doc-files-to-txt-using-libreoffice-from-the-command-line/38397232 * Others figuring out open instances of libreoffice are getting passed commands; but missing they can specify a per user environment etc. While --backtrace does exist, it isn't often too helpful. From IRC discussion: vmiklos: most logging is done using SAL_INFO() / SAL_WARN(), and those expand to nothing on release builds. Could a build of libreoffice (particularly what a lot of distros package up as libreoffice-headless) be configured to allow SAL_INFO/SAL_WARN to output to STDOUT/STDERR via a --verbose or --debug type argument if used with --headless. This would keep the existing silent behaviour for desktop users, but allow semi-technical users to gain some insight if they opt in.
Somewhat similar is Bug #42982 ; which highlights a similar problem in a different area.
The big question is who will deal with the regressions caused by turning --enable-sal-log on by default. The logging is there, but when it's used, the assumption is that performance is not a problem, since in a product build they'll expand to nothing.
So, the way I had imagined it is the various logging functions simply check log level/similar. While not a null operation, doing # Start up log_level = NONE if params["--headless"] && params["--debug=info"] log_level = INFO # On logging def log(msg) if log_level == NONE return fprintf (stderr, msg) Doesn't seem like on the face of it that you'd generate huge amounts of unnecessary IO or similar without user buy-in. If there's a lot of stuff emitted at the wrong log level (ie: more suited to proper DEBUG level logging instead of INFO), though it may produce a bit more memory consumption the implementation would be at the same time providing a wider audience the tools to find this stuff out.
(oh, and to be super clear: I'd be more keen on a specific build - if this is already taken care of as part of the nightlys or similar and as a relative outsider, I've just missed this entirely... that'd be handy to know!)
@Mike, any opinion on this topic ?
The logging in LO is done in places that developers consider useful during the development. At no place any of developers considered the cost of logging when added it in a place (well, I exaggerate a little, but still). So the logging might happen in places called thousands of millions times during e.g. loading of a real-life file. And having a couple of additional comparisons and a couple of indirections in a tight loop might well result in a considerable penalty. But that is just a speculation. Doers decide; so if anyone wants to give it a try, welcome to dev channel, and please feel free to try to implement the proposal (we would help answering questions, of course) - with necessary testing/profiling. If it turns out to be less problematic than anticipated - why not.
@Mike, thanks for your comment. Considering the time this issue has been in UNCONFIRMED status and the performance penalty it might cause, let's close it as RESOLVED WONTFIX