1i5t5.duncan at cox
Nov 15, 2009, 5:25 AM
Post #5 of 12
(963 views)
Permalink
|
|
Re: How to install multilib'ed version of any library (for real multilib for x86 and x86_64 for every libraries)?
[In reply to]
|
|
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
|
signature.asc
