Re: ia32-libs and dynamic loading paths
On 8/19/05, Christoph Best <cb_ubuntu@ttdom.de> 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
Reply to: