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 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": > 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. > Could one talk the glibc maintainers to allow that? I would hope so, because this is by far the best solution. Thomas