sean wrote:
> So would a chroot environment perhaps help with the problem apps?
> I am sure I am not the first on this path, so how have some you done who 
> have tried these games?

I've always found that the chroot just makes things work easier. Yes, 
you have a large investment period (creating the chroot), but in the end 
I've *always* found that it works better than trying to get the 32 bit 
emul-* libraries to work under x86_64.

Some programs mistakenly try and link to the 64-bit libs first, even if 
the 32-bit libs are available. I've had to create nasty LD_LIBRARY_PATH 
statements, and mess around with the order in ld.so.conf to get things 
to semi work.

Yes, this is also a shameless plug, but you will soon find that doing 
this to get into your chroot as your normal user:

$ sudo linux32 chroot /home/32-bit su - user1 -c id

starts to get very tiring...

Because of that, I created a utility that combines the code of those 
commands into one command. One problem though.. /home/32-bit is 
hard-coded in my utility, I wasn't able to come up with a secure way to 
read that parameter from a config file - and still keep the source small.

Here's the bugzilla for it:
http://bugs.gentoo.org/show_bug.cgi?id=111367

and here's a snippet from my web page about it:
http://www.gonoph.net/node/37

The ebuild is also in the archive. Another thing to note about 32-bit 
chroots:

in my 32-bit chroot, I've created symlinks from the main /home/ for all 
the users directories to point into the 32-bit chroot, I also bound /tmp 
(mount -bind) into the 32-bit chroot, as well as the root home directory 
/root. This gives me the advantage of switching in and out of the 
chroot, while still giving the illusion that I'm in the same home 
directory and same /tmp - and X clients that use unix pipes to 
communicate to the X server still work as well.
-- 
gentoo-amd64@g.o mailing list