Created attachment 1209519 [details] Printscreen of bug Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. open any document by Libreoffice via GUI 2. or start Libreoffice by cli: libreoffice test.odt 3. Actual results: I18N: X Window System doesn't support locale "cs_CZ.UTF-8" Expected results: Start Libreoffice Additional info: I can open document by command: LANG=en_US.UTF-8 libreoffice test.odt
The problem apparently is that LO's idea of character encoding used in the pathname /home/daridim/Stažené/test.odt doesn't match the OS's idea. What's the output of "locale; pwd" command on the command line, while in that /home/daridim/Stažené/ directory?
[12:56:18][dandim][~/Stažené]:locale; pwd LANG=cs_CZ.UTF-8 LC_CTYPE="cs_CZ.UTF-8" LC_NUMERIC="cs_CZ.UTF-8" LC_TIME="cs_CZ.UTF-8" LC_COLLATE="cs_CZ.UTF-8" LC_MONETARY="cs_CZ.UTF-8" LC_MESSAGES="cs_CZ.UTF-8" LC_PAPER="cs_CZ.UTF-8" LC_NAME="cs_CZ.UTF-8" LC_ADDRESS="cs_CZ.UTF-8" LC_TELEPHONE="cs_CZ.UTF-8" LC_MEASUREMENT="cs_CZ.UTF-8" LC_IDENTIFICATION="cs_CZ.UTF-8" LC_ALL= /home/dandim/Stažené
The symptoms smell like LO is doing a bad call to setlocale(2) in sal/osl/unx/nlsupport.cxx. (One result would be that the call to XSupportsLocale(3) in vcl/unx/generic/app/i18n_im.cxx, leading to the quoted stderr output. Another result would be that LO assumes pathnames in plain ASCII or ISO-8859-1 instead of UTF-8 notation, so wouldn't find files in paths containing non-ASCII characters, like /home/daridim/Stažené/test.odt, so would (silently) immediately terminate again when asked to open such a file.)
Hmm :-) If i moved file test.odt to home directory (/home/dandim/) i can open it! But if i moved back to /home/dandim/Stažené, i cannot open it again. Stažené mean Downloads (in English) :-) I looks like that LO has problem with characters in Czech "Stažené"...
Dandim, if you feel reasonably at home with gdb, what you could do is produce a trace of LO's setlocale calls, maybe that would give a clue. What you'd need to do is (ideally after installing the libreoffice debuginfo package): Run 'gdb /lib64/libreoffice/program/soffice.bin', enter the commands 'break setlocale' (upon which you may need to confirm 'y'), then 'commands' (prompt changes to '>'), 'backtrace', 'continue', 'end' (prompt changes back), 'run', then capture the gdb output.
Created attachment 1209750 [details] gdb_output
Ah, that's without glibc-debuginfo, so it doesn't print the arguments to the setlocale calls (hadn't thought about mentioning this; if you have time, it would be really great if you could redo the experiment after installing glibc debuginfo). But most of them should be of the "harmless" query-only kind with a null locale string argument (and when I checked myself under GNOME, the only call sequence that temporarily sets a new locale and then resets to the original one is the four calls from osl_getTextEncodingFromLocale right at the start). However, this is apparently under KDE, and maybe also with a relevant difference in Input Method support compared to the scenario I tested; will investigate further.
Sorry, but package glibc-debuginfo doenst exist in Fedora 25 repository. :-)
(In reply to Dandim from comment #8) > Sorry, but package glibc-debuginfo doenst exist in Fedora 25 repository. :-) 'dnf install-debuginfo glibc' should do it
Created attachment 1210177 [details] gdb2 output
Hi, i upgraded Libreoffice package (via updates-testing repo) to version LibreOffice 5.2.3.1. I have still problems with opening files.
Hi Stephan, any updates on this? I just hit this as well after upgrading from F24, and it is really annoying.
It seems this has something to do with a new version of libX11, see: https://bugs.archlinux.org/task/51442
Sorry, I'm still clueless as to what exactly fails there. (And I can't reproduce the issue.) But now there's apparently two users for whom it fails. What desktop system is each of you using, GNOME, KDE, ...? And after upgrading from F24, still using X11 or Wayland? And any changes in what exactly gets output to stderr and/or is displayed as a LibreOffice error box since attachment 1209519 [details]?
SAL_USE_VCLPLUGIN=gen soffice reproduces this
Created attachment 1260563 [details] simple X11 standalone program gcc demox.c -lX11
LANG=en_IE.UTF-8 ./a.out good LANG=de_DE.UTF-8 ./a.out good LANG=fi_FI.UTF-8 ./a.out good LANG=am_ET.UTF-8 ./a.out good LANG=sr_CS.UTF-8 ./a.out good LANG=cs_CZ.UTF-8 ./a.out bad
I had a look at this yesterday again after I found out that only one of two identical workstations suffered from this issue. I turned out that the one affected had glibc-langpacks-all and glibc-langpack-cs installed, while the other one had none of these but it had an old locale archive (probably from pre-F24 times). On the affected machine I removed both glibc-langpacks-all and glibc-langpack-cs, after which: - accented characters started working - the startup error message changed to "Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale." - it still was not possible to open files with non-ASCII characters anywhere in their path. Then I did "dnf reinstall libreoffice*" and "dnf install glibc-langpacks-all glibc-langpack-cs", and now everything works like a charm again! So - while the core issue is the libX11 bug, there is something weird going on in libreoffice as well.
*** This bug has been marked as a duplicate of bug 1383646 ***