"Andy Wang" <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Wed, 23 Apr 2008 23:43:16 -0500:
> This doesn't work for libraries that have additional modules that are > located in /usr/lib32/[moduledirectory] as I mentioned in my previous > comment when you have libraries built in a regular chroot environment > with a libdir of /usr/lib, it's going to look for > /usr/lib/[moduledirectory]/module.so which will be the 64-bit library > and thus incompatible That's a library search path issue, and would normally be solved by setting LDPATH appropriately. For that, drop a file as appropriate in /etc/env.d/ (see the existing files already there), and remember to rebuild the libloader cache (/etc/ld.so.cache, running env-update does this among other things) afterward. An exception would be plugins, as for firefox, etc. For 32-bit executables with plugins, you'll need to properly configure their search path to look in the 32-bit location. Of course, again, a chroot is a reasonably simple way to manage all this. Let the 32-bit system run in a chroot so it sees its own /lib and /usr/lib just as it would on a normal 32-bit system, and mount --bind stuff like /home (probably /tmp too, and maybe part or all of /var) as appropriate, so it appears in the chroot location as well. Then run all your 32-bit apps from the chrooted environment so they aren't looking at the 64-bit paths but instead their own (chrooted) 32-bit paths, and the setup I described should work, because as far as the 32- bit system is concerned, it's running on its own machine and doesn't even know about nor can it see* the 64-bit system. The 32-bit chroot method should be simpler and cleaner for the 64-bit system as well, which should then be perfectly fine running a no-multilib profile, with the exception of 32-bit execution turned on in the kernel, and a script that sets up the 32-bit stuff and enters the chroot. No more conflicts between 32-bit and 64-bit executables with the same name, no having to prioritize either 32-bit or 64-bit libraries first in the search order, etc. === * "See" here is taken in the convenience sense, not the security sense. As with any chroot, it's possible for an app to escape the chroot if it tries to do so, particularly if it is running as root. That shouldn't be an issue, however, in the purely convenience context of running the chroot simply to keep the 32-bit stuff from getting confused by the 64- bit system. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- [email protected] mailing list
