List Archive: gentoo-amd64
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
> 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:
and here's a snippet from my web page about it:
The ebuild is also in the archive. Another thing to note about 32-bit
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.
firstname.lastname@example.org mailing list