Thomas Steffen <[EMAIL PROTECTED]> writes: > On 8/19/05, Christoph Best <[EMAIL PROTECTED]> wrote: >> Goswin von Brederlow writes: >> > > libX11.so.2 loading the locale dependent libraries in >> > > /usr/X11R6/lib/locale/lib/common. This causes the "X11 locale not found > > Yes, I made the same observation some time ago, when I was trying to > run acrobat reader without a chroot. > >> I found a note on this problem at the end of >> http://www.linuxbase.org/futures/ideas/multiarch/ >> but it addresses apache plug-ins, > > Unfortunately it only notes the problem, but then does not give a > solution. The problem is of course a standard one, but there does not > seem to be a standard answer (yet?). > > Usually static compiled in paths are recommended:
The multiarch proposal specifies a subdir of <arch>-<os> for all architecture specific libaries and includes. That emidiatly resolves the problem since the X11 locales are then in: /usr/X11R6/lib/x86_64-linux/locale/lib/common /usr/X11R6/lib/i486-linux/locale/lib/common One directory per architecture. Either a hardcoded path or via ld.so will find the right one. >> > The right way to solve this is to compile the lib with multiarch >> > directories on all archs. >> >> I looked into the libX11 sources, and while it can take a list of >> directories to search, it does not check whether the loadable >> libraries are compatible and simply takes the first directory that has >> a locale.dir in it. > > Well, you just have to make sure that you configure the right > directory :-). Of course with more and more libraries using dynamical > modules, the limitation that you can't moves these libraries without > recompiling gets increasingly annoying. > > Option two is environment variables. That is *very* ugly, and it > completely prevents seamless interoperability between 32bit and 64bit > programs. > > So there is option three, some "runtime glue": How about relative paths? dlopen() on X11/locale/lib/common/xlcDef.so.2 should go through the search path and find the right one. >> Maybe one way to solve this would be to modify dlopen() to look at >> alternate locations by prepending /emul/target? Or at least to provide >> a dlopen_multiarch() that does that? > > Yes, several systems use this approach, which can be implemented in > the linker or in the kernel. Windows for example puts the libraries in > \Windows\system32. On a x64 system, this directory contains 64bit (!) > libraries. If a 32bit process tries to access this directory, it gets > redirectod to \Windows\Programs\WoW64 (!), where the 32bit libraries > are stored. But most other architecture emulators work the same way, > for example Mac-on-Linux. I have no idea why the 32bit subsystem in > the amd64 kernel does not do this. It does that. Currently x86_64 specs use /lib for 32bit and /lib64 for 64bit. Debian-amd64 PURE64 uses /lib for 64bit with /lib64 linked there so we can't use /lib for 32bit again. We use /emul/ia32-libs/lib instead. Ubuntu went ahead and used /lib32 instead like IA64 does. Pure64 was never intended to run 32bit code. As the name says, it was for just 64bit code. >> Could one talk the glibc maintainers to allow that? > > I would hope so, because this is by far the best solution. > > Thomas Gcc, binutils and glibc all three have to agree on this. There are quite interwoven there. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]