When I start a recent daily build, I get several console log lines saying: warn:sal.textenc:27617:27617:sal/textenc/textcvt.cxx:187: Missing rtl_TextToUnicodeConverter Well, 1. The message should say _what_ is missing that rtl_TextToUnicodeConverter. 2. The message should say what kind of entity is missing: Is it a section in a file? A function which should have been available to LO via a dynamic library? A configuration setting? I would probably have another complaint or two if I knew the answer to these questions. Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: c1659be6ff0e0c91e0c7d1e6acb6ab18821e2bf7 CPU threads: 4; OS: Linux 5.9; UI render: default; VCL: gtk3 Locale: en-US (en_IL); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-03-02_06:18:34
This trace has been added with 870617882366232aa4ff9aa2faaae1cad2bbc3f8 author Stephan Bergmann <sbergman@redhat.com> 2017-09-28 14:32:49 +0200 committer Stephan Bergmann <sbergman@redhat.com> 2017-09-28 14:41:23 +0200 commit 870617882366232aa4ff9aa2faaae1cad2bbc3f8 (patch) tree 89d5423d52a7aeb9f564a2f3fd4177350cc78ec1 parent 4b88f3545c9525146327470ea767041d6de4c7ca (diff) Warn about missing text converter (probably because the encoding is RTL_TEXTENCODING_DONTKNOW; that may still happen in various places, so can't use anything stronger than SAL_WARN here) Found with this command line (which supposes having git clone LO repo) git log --follow -S 'Missing rtl_TextToUnicodeConverter' sal/textenc/textcvt.cxx Now without stacktrace, difficult to tell where's the root cause. I don't know your knowledge about Linux or dev tools like gdb but if you know a bit, in gdb you can put a break at this line and retrieve a backtrace. Stephan: do you think about a piece of info which could be added in this log?
BTW, here are the only logs I got on pc Debian x86-64 with master sources updated today + enable-dbgutil + gtk3 when launching an odb file (HSQL embedded): warn:legacy.osl:26721:26721:dbaccess/source/core/dataaccess/ModelImpl.cxx:771: ODatabaseModelImpl::getOrCreateRootStorage: no source to create the storage from! warn:legacy.osl:26721:26721:dbaccess/source/core/dataaccess/ModelImpl.cxx:771: ODatabaseModelImpl::getOrCreateRootStorage: no source to create the storage from! warn:legacy.osl:26721:26721:dbaccess/source/core/dataaccess/ModelImpl.cxx:771: ODatabaseModelImpl::getOrCreateRootStorage: no source to create the storage from!
(In reply to Eyal Rozenberg from comment #0) > 1. The message should say _what_ is missing that rtl_TextToUnicodeConverter. > 2. The message should say what kind of entity is missing: Is it a section in > a file? A function which should have been available to LO via a dynamic > library? A configuration setting? These warning messages are targeting a developer audience (similar to C/C++ asserts). And the information they provide needs to take into account the cost of obtaining that information. For example, in this specific case, the given SAL_WARN is already presenting all the relevant information that is available locally (i.e., close to zero). If you are uncomfortable with seeing such warning messages on stderr, you should probably not be running "a recent daily build". > I would probably have another complaint or two if I knew the answer to these > questions. This isn't a venue to air complaints. If you see an issue besides the stderr output itself that you want to report, then please state that issue, as clearly and as thoroughly as possible.
Closing as RESOLVED NOTABUG based on comment 3
(In reply to Xisco Faulí from comment #4) > Closing as RESOLVED NOTABUG based on comment 3 Xisco, I explained why it is a bug in my opening comment. To reiterate in light of comment 3: Yes, it's ok to print warnings when something is wrong/missing. But - something being wrong/missing is a bug, by definition. And if the "unicode converter" isn't really missing, then the warning is just console noise and should be avoided. So the only question is which kind of bug this is, not whether it's a bug.
rtl_ prefix here has no relation to right-to-left (I don’t actually know what i stands for, runtime library?).
(In reply to خالد حسني from comment #6) > rtl_ prefix here has no relation to right-to-left (I don’t actually know > what i stands for, runtime library?). yes, runtime library (see sal/rtl/)