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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]