Re: ia32-libs and dynamic loading paths
Thomas Steffen writes:
> > 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 (it is actually the ld.so loader program that does it) - but
only for libraries that don't have an explicit path specified.
The problem here is with explicitly loaded libraries like
plug-ins. Here, the loading is done using dlopen() using an absolute
path, and only this path is searched. This makes sense since some
programs have many small loaddable plug-ins (e.g. 32 libraries in my
system for libpam in /lib/security) and they should not be visible to
other programs. For pango, these paths are specified e.g. in
/etc/pango/pango.modules.
Maybe I'll try to modify dlopen() to prepend "/emul/ia32" if the file
cannot be loaded and see if this solves the problems. I do not think
this should break anything.
-Christoph
--
Christoph Best cbst at tigertiger de
Max-Planck-Institute of Biochemistry, Munich http://tigertiger.de/cb
Reply to: