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

[Andy Wang]

On Thu, Apr 24, 2008 at 11:40 AM, Duncan <1i5t5.duncan@×××.net> wrote:

>  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.

No, LDPATH modifies the ld.so.conf, which affects runtime dynamic
linking.  It doesn't affect things that don't use the standard ld.so
dynamic linker.  To give you an example, take a look the gnome-vfs
package.  It places a bunch of binary files in
/usr/lib/gnome-vfs-2.0/modules.  The location to these libraries are
fixed during configure/compile time via the libpath location given to
configure.  I can screw with LDPATH and LD_LIBRARY_PATH all I want and
it won't make a bit of difference.

>  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.

Sure, but not all applications allow you to reconfigure the module
location at runtime.  Many of the gnome libraries, such as gnome-vfs
that I gave as an example above, don't have a simple way of overriding
where it finds it's modules at runtime.

>  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.

I don't really want to debates the merits of a multilib vs. chroot
system as it's not my point.  There are pros and cons for both.
Suffice it to say, I'm not happy with a chroot 32-bit environment I
don't think it's simpler and cleaner than a multilib environment and
it's not acceptable for me to have to deal with a 32-bit chroot
environment.  Until gentoo moves to a true multilib environment were
every library package can be built with both 32-bit and 64-bit I'm
more than happy to maintain my own emul-linux-x86-* packages.  I just
want to know how to do it in a way that's most like how the gentoo
devs are creating their packages.
-- 
gentoo-amd64@l.g.o mailing list