Bugzilla Bug 62110

# strings libX11.so|grep X11/locale
/usr/X11R6/lib/X11/locale

Of course, it should be /emul/linux/x86/usr/X11R6/lib/X11/locale. As it is, when running a locale-aware 32bit app, the loader tries to load (64bit) modules from /usr/X11R6/lib/X11/locale/lib/common and obviously fails.

Further, /emul/linux/x86/usr/X11R6/lib/X11/locale dir is unusable. At the very least, "locale.dir" must be present there (though why not have a complete locale support for 32bit X apps?).

Because of these two bugs, 32bit apps either warn about locale being disabled (e.g. ooffice) or simply crash (e.g. acroread).


Reproducible: Always
Steps to Reproduce:

For a temporary workaround, see
http://forums.gentoo.org/viewtopic.php?p=1481423#1480559

Well, your workaround doesn't work for me. :-/

Which of the two (regarding the .../locale/ dir contents)? Does acroread still
warn about unsupported locale? You can strace the exec and see if it tries to
access something other in /usr/X11R6 as well.

PS. I use the emul-x86 packages for ~amd64.

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

Well, i think i got it working now... the C subdir of .../locale/ was broswed
for files by Acroread, and it segfaulted there, searching for missing
XI18N_OBJS. I'll fixed the xlibs now as well as the acroread ebuild.

Thx Evgeny!

Hmm, if emul-xlibs is fixed (i.e. /usr/X11R6/.. isn't wrongly hardcoded as
default), there should be no need to alter Acroread. Actually, I first managed
to get it running by binary editing of the emul's libX11.so, replacing
X11/locale -> X11/local1 and making it a symlink to /emul/.../locale.

Workaround is workaround... won't touch it anymore until we finally have the
chance to do: rm lib; ln -s lib32 lib ;-)

Hmm, this fix doesn't really work for me. I still have to copy the contents of
/usr/X11R6/lib/X11/locale (lib + C excepted) to
/emul/linux/x86/usr/X11R6/lib/X11/locale, but then everything works fine and
acroread doesn't complain anymore.

i'm already working on this, and it depends on making xorg lib64-aware

when xorg is lib64 aware, the fix is simply making lib a symlink into our 32bit
emul libs, no copying needed.

> Hmm, this fix doesn't really work for me. I still have to copy the contents of 
> /usr/X11R6/lib/X11/locale (lib + C excepted) to 
> /emul/linux/x86/usr/X11R6/lib/X11/locale

Quite possible, if your working locale is anything but C/POSIX. Don't you think
all these dirs in .../locale are only for the faint of heart? ;-) That's why I
originally wrote "why not have a _complete_ locale support for 32bit X apps?".

> when xorg is lib64 aware, the fix is simply making lib a symlink into our 
> 32bit emul libs, no copying needed.

Hmm, I've been always fond of Gentoo having lib dirs linked to the proper, 64bit stuff. The real culprit here is X, of course. The whole /usr/X11R6 directory tree is quite a mess, with no thought paid to separating into arch-dependent and -independent parts. If /usr/X11R6/lib/X11/locale/lib/*/* were put in /usr/X11R6/lib and /usr/X11R6/lib/X11/locale - in /usr/X11R6/share, there would be no such an issue in the first place. Et cetera. Not to mention the brain-damaged approach to loading dlls at run time with hardcoded paths as we see here (which also, BTW, breaks the ability to _statically_ link an X app and run it on another distribution).

Let's hope X.org folks do this right...

/usr/X11R6/lib/X11/locale/lib/ is as it should be.
/usr/X11R6/lib64/X11/locale/lib64/ will also be as it should be.

the problem is made confusing only because /usr/X11R6/lib and /usr/X11R6/lib64 point to the same place in gentoo right now. >_< if lib werent broken in the way you seem fond of, this wouldnt be a problem at all.

...though i do agree about moving the non-lib locale stuff out to /usr/share. it does indeed make a lot more sense there. perhaps you should file a bug upstream with xorg? i must say, xorg has some amazing upstream support.


anyways, this bug is fixed as well as it can be now, and it should be fixed for apps other than adobe acrobat, IF you are using the new xorg-x11-6.7.99.903 ebuild and the new xlibs ebuild. md5sums:

0474908da429f67f670be8c4f77cc0b0  /portcvs/x11-base/xorg-x11/xorg-x11-6.7.99.903.ebuild
b43083f959211bf6bfcbc0575838f11c  /portcvs/app-emulation/emul-linux-x86-xlibs/emul-linux-x86-xlibs-1.2-r1.ebuild

the new xorg depends on changes made to the eutils eclass. md5sum:

e26900c92ca4afabf00b5557f45a7a25  /portcvs/eclass/eutils.eclass

> if lib werent broken in the way you seem fond of, this wouldnt be a problem at all.

I'm not sure whether we're talking about the same thing, but I find it pleasant
when the same Makefile works for all platforms with no need to replace e.g.
/usr/X11R6/lib with /usr/X11R6/lib64 etc. And not only I do; see e.g.
http://lwn.net/Articles/79036/

> perhaps you should file a bug upstream with xorg

Given key X.org figures consider moving /usr/X11R6/* to /usr altogether, there
is probably no need...

heh... like i said, great upstream support. :)

i'll be soooo happy when they kill off imake. it just sucks that debrix wasnt ready for 6.8