Re: ia32-libs and dynamic loading paths
Thomas Steffen <steffen.list.account@gmail.com> writes:
> 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 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
Reply to: