Missing symlink from /usr/lib/X11/locale/common to /usr/share/X11/locale/lib/common

[Mike Vitale]

I updated/upgraded this morning (25-Jul-2005), and since then, any Java GUI
application I've attempted to run has failed. When run from commandline, they
exit without reason or comment. Running under strace gives a reason of:

waitpid(-1, current locale is not supported in X11, locale is set to CX locale
modifiers are not supported, using defaultjava.lang.InternalError: Current
locale is not supported

(Yes, that's how it shows up in my terminal, missing-newlines and all.)

I don't remember which packages got updated this morning, but this all was
working fine on Friday (22-Jul-2005) on this very system. Help!

[David Grant (david-grant)]

I have also run into this problem, and no amount of locale-fiddling resolves it.

[Mike Vitale (ubuntu-bugs-mikevitale)]

So....what *does* resolve it?

[Mike Vitale (ubuntu-bugs-mikevitale)]

Walking through an strace of trying to run HelloWorldSwing.java led me to this
section:

open("/usr/lib/X11/locale/locale.alias", O_RDONLY) = 5
fstat64(5, {st_mode=S_IFREG|0644, st_size=29144, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xaa6e3000
read(5, "#\t$XdotOrg: xc/nls/locale.alias,"..., 4096) = 4096
read(5, "\t\tda_DK.ISO8859-15\nda_DK.8859-15"..., 4096) = 4096
read(5, "n_ZA.ISO8859-15\nen_ZA.iso885915\t"..., 4096) = 4096
read(5, "CH.ISO8859-1\nfr_CH.88591.en\t\t\t\t\t"..., 4096) = 4096
read(5, "GE.GEORGIAN-ACADEMY\nka_GE\t\t\t\t\t\tk"..., 4096) = 4096
read(5, "ISO8859-1\npt_BR.88591.en\t\t\t\t\tpt_"..., 4096) = 4096
read(5, "r_PK.microsoftcp1256\t\t\t\tur_PK.CP"..., 4096) = 4096
read(5, "1\nturkish\t\t\t\t\ttr_TR.ISO8859-9\ntu"..., 4096) = 472
read(5, "", 4096) = 0
close(5) = 0
munmap(0xaa6e3000, 4096) = 0
open("/usr/lib/X11/locale/locale.dir", O_RDONLY) = 5
fstat64(5, {st_mode=S_IFREG|0644, st_size=15664, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xaa6e3000
read(5, "XCOMM\t$XdotOrg: xc/nls/locale.di"..., 4096) = 4096
read(5, "so8859-1/XLC_LOCALE:\t\t\tes_PY.ISO"..., 4096) = 4096
read(5, "859-2/XLC_LOCALE:\t\t\tsr_SP.ISO885"..., 4096) = 4096
read(5, "C_LOCALE:\t\t\tes_PR.UTF-8\nen_US.UT"..., 4096) = 3376
read(5, "", 4096) = 0
close(5) = 0
munmap(0xaa6e3000, 4096) = 0
open("/usr/lib/X11/locale/en_US/XI18N_OBJS", O_RDONLY) = 5
fstat64(5, {st_mode=S_IFREG|0644, st_size=345, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xaa6e3000
read(5, "# CATEGORY(XLC|XIM|OM)\tSHARED_LI"..., 4096) = 345
read(5, "", 4096) = 0
close(5) = 0
munmap(0xaa6e3000, 4096) = 0
open("/usr/lib/X11/locale/common/xlcUTF8Load.so.2", O_RDONLY) = -1 ENOENT (No
such file or directory)
write(2, "current locale is not supported "..., 58current locale is not
supported in X11, locale is set to C) = 58
open("/usr/lib/X11/locale/locale.alias", O_RDONLY) = 5
fstat64(5, {st_mode=S_IFREG|0644, st_size=29144, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xaa6e3000
read(5, "#\t$XdotOrg: xc/nls/locale.alias,"..., 4096) = 4096
read(5, "\t\tda_DK.ISO8859-15\nda_DK.8859-15"..., 4096) = 4096
read(5, "n_ZA.ISO8859-15\nen_ZA.iso885915\t"..., 4096) = 4096
read(5, "CH.ISO8859-1\nfr_CH.88591.en\t\t\t\t\t"..., 4096) = 4096
read(5, "GE.GEORGIAN-ACADEMY\nka_GE\t\t\t\t\t\tk"..., 4096) = 4096
read(5, "ISO8859-1\npt_BR.88591.en\t\t\t\t\tpt_"..., 4096) = 4096
read(5, "r_PK.microsoftcp1256\t\t\t\tur_PK.CP"..., 4096) = 4096
read(5, "1\nturkish\t\t\t\t\ttr_TR.ISO8859-9\ntu"..., 4096) = 472
read(5, "", 4096) = 0
close(5) = 0
munmap(0xaa6e3000, 4096) = 0

The critical part here being the ENOENT near trying to open
"/usr/lib/X11/locale/common/xlcUTF8Load.so.2". /usr/lib/X11/locale exists.
/usr/lib/X11/locale/common does not. /usr/share/X11/locale/lib/common does
exist, ...

[Daniel Stone (daniels)]

this is fixed in current Breezy, btw

[Andrew Piskorski (atp)]

Is this bug really "fixed"? And if it is fixed, precisely HOW was it
fixed?

Note that as of 2005-09-29, Edsel Adap says here that this bug is
definitely NOT fixed:

  http://www.adap.org/~edsel/blog/archives/42

And AFAICT, he is completely correct - it is not fixed.

[Andrew Piskorski (atp)]

FYI, my up (recently installed and up to date) Breezy x86_64 system
has this:

  $ ls -ld /usr/share/X11/locale/lib/common /usr/lib/X11/locale/common
  ls: /usr/share/X11/locale/lib/common: No such file or directory
  drwxr-xr-x 2 root root 4096 2005-11-09 10:55 /usr/lib/X11/locale/common

  $ dpkg-query -S /usr/lib/X11/locale/common
  libx11-6: /usr/lib/X11/locale/common

In my case, I've found that the Oracle 10gR2 64 bit Java Installer
definitely does NOT work on Ubuntu AMD64, with symptoms that are very,
very similar to those described in this bug. Some related info is
here:

http://groups.google.com/group/linux.debian.ports.x86-64/browse_frm/thread/7368b5e597b68fb/
  http://openacs.org/forums/message-view?message_id=337745

[Daniel Stone (daniels)]

yes, I'm saying this bug is "fixed", because we don't use
/usr/share/X11/locale/lib/common at all:
daniels@ephemera:~/canonical/merge% grep /usr/share/X11/locale/lib/common
/usr/lib/libX11.so.6.2.0
zsh: exit 1 grep /usr/share/X11/locale/lib/common /usr/lib/libX11.so.6.2.0

i don't know why java insists on opening all these files, but it's not
libx11-6's problem at all. so that's why this bug is "fixed".