Bugzilla Bug 80420

Emerge xorg-x11-6.8.1.902, change xorg.conf accordingly, fire up 32 bit mozilla
and it reports:

(mozilla-bin:15979): Gdk-WARNING **: locale not supported by Xlib
(mozilla-bin:15979): Gdk-WARNING **: can not set locale modifiers

The result is that I can't cut and paste to/from mozilla and many other
applications, such as rxvt.

I then follow the instructions on this post:

http://forums.gentoo.org/viewtopic.php?p=1609855#1609855

And I can now cut and paste again. But one thing it does not fix is this:

(mozilla-bin:16237): Gdk-WARNING **: Error converting from UTF-8 to STRING:
Conversion from character set 'UTF-8' to 'ISO-8859-1' is not supported

Which I suspect is what causes me to still not be able to cut and paste between
32 bit mozilla and my 32 bit binary only editor, visual slick edit. Yeah yeah,
I don't want to hear about the "well, get an open source editor". This is what
we use at my work and I'm happy to be able to use Linux as my workstation at
work and have a damn good editor that works well in my favorite OS.

Reproducible: Always
Steps to Reproduce:
1. Read details
2.
3.

cd /usr/X11R6/lib/X11/locale/
ln -s /emul/linux/x86/usr/X11R6/lib/X11/locale/lib

Seems to fix it.

More interesting developments:

(mozilla-bin:20104): Gdk-WARNING **: Error converting from UTF-8 to STRING: Could not open converter from 'UTF-8' to 'ISO-8859-1'

This is "solved" thusly:

cd /usr/lib
mv gconv gconv64
ln -s /usr/lib32/gconv

Obviously not a real solution, but this does tell me where it's looking for the files. I'd _love_ to be able to use strace, but any time I invoke strace -f, strace itself seg faults.

An even better solution:

GCONV_PATH=/usr/lib32/gconv mozilla

Now to fix the last (seemingly innocuous) output mozilla produces:

(mozilla-bin:20306): Gtk-WARNING **: Unable to locate theme engine in module_path: "pixmap",

This seems to be due to it not being able to open libpixmap.so, which is supposed to be in /usr/lib32/gtk-2.0/2.4.0/engines. I symlinked my 32 bit chroot's directory, and it still failed with the error g_return_if_fail_warning, which seems to exist in libgdkmm-2.0.so, which doesn't exist in emul libs.

Seems that we still have a long way to go with multilib...sigh...

well the "looking in /usr/lib/gconv" problem won't be fixed until the lib/lib64
symlinking is removed in 2005.1.  If you want to be a guinea pig, youu can try
updating to 2005.0/no-symlinks or even 2005.0/no-symlinks/no-lib32.  Talk with
me on IRC if you're willing to give it a try.

As for the other stuff, we can probably update emul-*-x11 with a workaround.

*** Bug 80922 has been marked as a duplicate of this bug. ***

Created an attachment (id=50636) [edit]
patch to fix error in emul-linux-x86-xlibs-1.2-r4.ebuild

just worked out why acroread no longer works with the
emul-linux-x86-xlibs-1.2-r4. It seems that there is a problem with the order of
a couple of commands, files get copied from one place to another and then later
deleted (when it is supposed to be just a symlink that gets deleted). I can't
see what this has to do with this bug but it was marked as a duplicate of it
so...

emul-linux-x86-xlibs-1.2-r5 is in CVS now - it should hit the mirrors soon.
This has the patch applied from Herbie Hopkins in the above comment - I tested
it and this resolves issues on my system with acroread.

No joy, I'm afraid.  I've installed emul-linux-x86-xlibs-1.2-r6, and the same
problem exists.  I've tried unmerging and re-emerging both emul-linux-x86-xlibs
and acroread, but that didn't help.

Running an strace, it appears that the symlinks in
/usr/X11R6/lib32/X11/locale/lib/common are pointing to the wrong place.  For
example:
   xlcDef.so.2 -> ../../../../xlcDef.so.2
This library is actually in
/usr/X11R6/lib64/X11/locale/lib64/common/xlcDef.so.2 so the link should point
to ../../../../../lib64/X11/locale/lib64/common/xlcDef.so.2 if that's what is
intended.

No, acroread wants 32 bit libraries.

It seems that there are still problems for some people with the recent changes to emul-linux-x86-xlibs. I am one of them, but I've managed to circumnavigate the problem by creating symlinks to make everything point to the right place.

The bottom line is that you need a /usr/X11R6/lib/X11/locale/lib that points to the correct location:

cd /usr/X11R6/lib/X11/locale/lib

Ensure there's no lib directory or symlink already present. If so, remove or rename it. Then:

ln -s /emul/linux/x86/usr/lib/X11/locale/lib

That should fix it. It fixed it for me.

What I ended up doing was unmerged all of the installed emul-linux-x86-*
packages (baselibs, compat, glibc and xlibs), then removed whatever was left in
/emul (a few orphaned libraries and symlinks.)  After reinstalling the
packages, acroread now runs fine.

Thanks.

I am marking this bug as fixed, as with the recent changes I believe it to be
on all but a few systems with damaged symlinks (improved logic to deal with
that also present now). This seems to fix it in the majority of cases - if you
still have problems please reopen.