[gentoo-amd64] Re: How to install multilib'ed version of any library (for real multilib for x86 and x86_64 for every libraries)?

[Duncan]

Nikos Chantziaras posted on Sat, 14 Nov 2009 17:16:35 +0200 as excerpted:

> On 11/14/2009 01:45 PM, Cheng Renquan wrote:
>>[...]
>> Furthermore, if compiling any other 32bit program on gentoo-amd64, it
>> may need other more 32bit of libraries,
>>
>> Comparing other linux distros like fedora-x86_64 and debian-amd64, I
>> knew there is simple way to archive this goal, just install both
>> binutils.x86_64 and binutils.i686
>> packages, but on gentoo-amd64, how can we do this in a similarly simple
>> way?
>>
>> How about add USE multilib support of every package that contains
>> libraries?
>
> Gentoo doesn't support this yet.  Work is underway to enable real
> multilib support though.

Nikos is correct... as far as he goes, but there are actually ways around 
it that he didn't describe.

First, for a limited subset of libraries, there are pre-compiled x86_32 
compatibility versions available.  This is the "fast" solution, workable 
for most mainstream stuff, but in addition to being limited to the 
mainstream libraries, it isn't really gentoo-like in some ways as the 
binaries are all precompiled, and for all the reasons that people choose 
Gentoo, that's just not really satisfying to many Gentooers.  Never-the-
less, it suffices for many apps and most 32-bit games.

The operative hint you need here is app-emulation/emul-linux-x86-*.  
Those packages are the various more-or-less mainstream pre-compiled 
x86_32 libraries.   FWIW, there's a limited number of executables, as 
well, normally with the -bin suffix.  mozilla-firefox-bin is one 
example.  These aren't as popular (some would say necessary) as they once 
were, as there are now various 64-bit binary plugins for stuff such as 
flash, but for quite some time 64-bit was out in the cold in that regard, 
so if you chose to run proprietary-ware at all, you generally found the 
32-bit versions helpful as they'd run the proprietary 32-bit-only plugins 
and codecs, etc.

The far less limited (virtually unlimited) and perhaps more Gentoo-ish 
but also MUCH more complicated and MUCH more work second alternative is 
to run a 32-bit chroot.  The problem is that at this point, none of the 
package managers (at least not portage, and I don't believe paludis or 
pkgcore have the feature either) can properly track multiple ABI/bitness 
versions of the same package.  Thus, for amd64, the package manager 
assumes all the packages are 64-bit, and if you were to merge one as 32-
bit, it would replace the 64-bit version of the same package.

The way around this is the 32-bit chroot.  The idea, basically, is to 
setup a second instance of Gentoo in a chroot, so the portage (or other 
PM) running there doesn't know about the main 64-bit system, and the 64-
bit system for the most part ignores the 32-bit chroot because it's not 
in its way.  You mount-bind a few subtrees, typically /tmp, often 
/home, a couple others (I was going to use etc, instead of "a couple 
others", but then realized that was ambiguous, NOT /etc!), into the 
chroot, so they're seen by both systems, start from a normal x86 stage 
tarball, and with some notable exceptions, basically, install an almost 
complete 32-bit system in the chroot.  In theory, you can skip many of 
the services, syslog, cron, etc, because the main system provides them 
for both.  In fact, since you have a nearly complete 32-bit system 
anyway, in many cases it's worth it to just do the whole thing (but maybe 
without the full X, kde/gnome, whatever, or maybe with it, depending on 
your goals for the respective sides), and then be able to dual boot to 
one or the other as desired.

There's more documentation, including a nice Gentoo/AMD64 32-bit chroot 
guide, available.  See the documentation section at the Gentoo/AMD64 
project page.  As you're asking about this, you probably haven't read the 
FAQ yet, so I'd start with that.  You're likely to find a few of your 
other questions answered there.  If after that (and reading the above) 
you're interested in the 32-bit chroot idea, you can read the 32-bit 
chroot guide and then decide if it's worth it or if you want to try the 
emul-linux-x86 stuff first.

Here's the Gentoo/AMD64 project page link.
Again, check the documentation section.

http://amd64.gentoo.org

One more possibility.  If you only have one or two libraries you need 
that aren't available as precompiled binaries in the emul-* packages, 
once you have the 32-bit dependencies installed, you may well be able to 
compile them manually, outside portage, using -m32.  However, once you 
get more than a couple to worry about, the complexity of trying to handle 
all the dependencies manually increases more or less geometrically 
proportional to the number of packages you're trying to handle, so it 
very quickly becomes easier to simply do the chroot and let portage's 
automation handle it.  YMMV.

Finally, a bit more detail on what Nikos hinted at.  There's a couple of 
experimental projects whereby portage is modified to be able to handle 
multiple ABI installations in parallel.  As a matter of practice, I don't 
know if they'll ever get merged, because we've gone this long without it, 
and as I mentioned, the worst need was along about 2006 or so, when a lot 
of folks had switched already but Flash and etc weren't yet available for 
64-bit, and even mainstream FLOSS apps like Open Office hadn't been 
ported.  Since pretty much everything mainstream FLOSS has been ported 
now, and the proprietaryware folks are coming around to 64-bit as well, 
there's far less need for multilib in general than there used to be, and 
the need/demand will be ever weaker with time.  If Gentoo/AMD64 got along 
this long without it, and since we're well past the hump, now, there's 
little real practical reason to worry about it -- for Gentoo/AMD64, at 
least.  But of course there's other archs it would benefit as well, some 
of which have more than two variants, and at least for the devs and arch-
testers, it could be very useful to be able to be able to install, test 
and otherwise work on multiple bitnesses at once.  But AMD64 was the big 
one, and the others too have gone this long without it.  So really, what 
it comes down to is whether enough devs prioritize it high enough to 
continue pushing it until it's not only working well, but until the other 
devs accept it as worth the hassle, an it becomes a part of portage (and/
or the other PMs) and Gentoo in general.  Yes, there's a couple devs 
working on it, but whether their pet project will remain of /enough/ 
interest to them for long enough to be worth pushing into mainline 
Gentoo, is anyone's guess.

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