On Thu, Apr 24, 2008 at 11:40 AM, Duncan <[EMAIL PROTECTED]> 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. -- [email protected] mailing list
