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
