80420 2005-02-01 23:38 0000 Locale issue with 32 bit mozilla in amd64 with xorg-x11 -6.8.1.902 2005-04-09 16:45:29 0000 1 1 1 Unclassified Gentoo Linux Library unspecified AMD64 Linux RESOLVED FIXED P2 normal --- 1 vi@sh.nu amd64@gentoo.org birder@ozemail.com.au eradicator@gentoo.org kugelfang@gentoo.org vi@sh.nu 2005-02-01 23:38:40 0000 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. vi@sh.nu 2005-02-02 00:41:54 0000 cd /usr/X11R6/lib/X11/locale/ ln -s /emul/linux/x86/usr/X11R6/lib/X11/locale/lib Seems to fix it. vi@sh.nu 2005-02-02 01:32:18 0000 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. vi@sh.nu 2005-02-02 01:36:19 0000 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... eradicator@gentoo.org 2005-02-02 10:29:28 0000 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. eradicator@gentoo.org 2005-02-07 01:59:09 0000 *** Bug 80922 has been marked as a duplicate of this bug. *** herbs@gentoo.org 2005-02-07 10:20:28 0000 Created an attachment (id=50636) 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... cryos@gentoo.org 2005-02-07 12:13:52 0000 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. birder@ozemail.com.au 2005-02-08 02:19:21 0000 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. vi@sh.nu 2005-02-08 09:23:02 0000 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. birder@ozemail.com.au 2005-02-08 12:02:19 0000 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. cryos@gentoo.org 2005-04-09 16:45:29 0000 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. 50636 2005-02-07 10:20 0000 patch to fix error in emul-linux-x86-xlibs-1.2-r4.ebuild emul-linux-x86-xlibs-1.2-r4.patch text/plain LS0tIGVtdWwtbGludXgteDg2LXhsaWJzLTEuMi1yNC5lYnVpbGQub3JpZwkyMDA1LTAyLTA3IDE4 OjAyOjE0Ljc5MjkxMDI4OCArMDAwMAorKysgZW11bC1saW51eC14ODYteGxpYnMtMS4yLXI0LmVi dWlsZAkyMDA1LTAyLTA3IDE4OjA5OjEwLjkzNzY0NjY3MiArMDAwMApAQCAtMzQsMTIgKzM0LDEy IEBACiAJY3AgJHtGSUxFU0RJUn0vWEkxOE5fT0JKUyAke0R9L2VtdWwvbGludXgveDg2L3Vzci9s aWIvWDExL2xvY2FsZS9DLwogCWNwICR7RklMRVNESVJ9L1hMQ19MT0NBTEUgJHtEfS9lbXVsL2xp bnV4L3g4Ni91c3IvbGliL1gxMS9sb2NhbGUvQy8KIAorCXJtIC1mICR7RH0vZW11bC9saW51eC94 ODYvdXNyL2xpYi9YMTEKIAltdiAke0R9L2VtdWwvbGludXgveDg2L3Vzci9YMTFSNi9saWIvKiAk e0R9L2VtdWwvbGludXgveDg2L3Vzci9saWIvCiAKIAkjIFdlIGRvbid0IHVzZSB0aGlzIGFueSBt b3JlCiAJcm0gLXJmICR7RH0vdXNyL1gxMVI2CiAJcm0gLXJmICR7RH0vZW11bC9saW51eC94ODYv dXNyL1gxMVI2Ci0Jcm0gLWYgJHtEfS9lbXVsL2xpbnV4L3g4Ni91c3IvbGliL1gxMQogCiAJZG9z ZWQgInM6XmxpYmRpcj0uKiQ6bGliZGlyPVwnL2VtdWwvbGludXgveDg2L3Vzci9saWJcJzoiIC9l bXVsL2xpbnV4L3g4Ni91c3IvbGliL2xpYkdMVS5sYQogCg==