[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: