[gentoo-amd64] Re: building emul-linux-x86 files

[Duncan]

"Andy Wang" <dopey74@×××××.com> posted
17dc8bc70804232143k1572c362pf1b3adfaa8d72f66@××××××××××.com, 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

-- 
gentoo-amd64@l.g.o mailing list