[gentoo-amd64] Re: Multilib or not?

[Duncan]

Tonko Mulder <tonko.mulder@×××××.com> posted
1227247224.6358.3.camel@Gaius, excerpted below, on  Fri, 21 Nov 2008
07:00:24 +0100:

> I was wondering since flash has been released for x86_64 and simply
> can't find a program on my laptop which uses emul-linux-x86-* If I could
> just move to a no-multilib profile.
>
> As I've read, life get's easier with the no-multilib profile. :)

The big question is whether you need anything 32-bit only, which is 
pretty much proprietary stuff.  I'm on the no-multilib profile, but the 
question was easy for me since I don't do proprietaryware.

In addition to flash, which should now cease to be a 32/64-bit issue, 
there's also various codecs, etc.  While there's 64-bit options for many 
codecs (I've personally had better luck with xine-lib and its many USE 
flags than mplayer, YMMV) including normal wmv, DRMed formats (including 
DRMed wmv) and real can be problems.  Specifically for xine-lib, the 
real, vidix and win32codecs USE flags are profile-masked because they are 
32-bit only.  IIRC there's a win64codecs package but I'm not sure of its 
status

The other big problem would be proprietary games.  If you prioritize 
being able to play them very highly, you'll almost certainly want to stay 
multilib.

HOWEVER, it's worth noting that there *IS* an alternative 32-bit solution 
to multilib.  It's more work, but in some ways it's truer to Gentoo's 
roots.  This is the 32-bit chroot solution sometimes mentioned.  With 
multilib, glibc and gcc (the big ones, also sandbox and binutils) are 
compiled for both 64-bit and 32-bit support, but pretty much everything 
else is installed from precompiled binaries.  This includes all the emul-
linux-x86-* libraries and the various *-bin executables (mozilla-firefox-
bin, mplayer-bin, etc) packages.  With a 32-bit chroot solution (for 
which there's Gentoo documentation if interested), you start from a 
standard x86 (32-bit) stage tarball and do much of a 32-bit installation 
as if from scratch, so after you're done you have almost an entire 32-bit 
installation paralleling your 64-bit installation (but missing system 
services like syslog, etc, since the 64-bit main system side provides 
those services, all compiled from sources, and you maintain them both as 
you normally would.  As I said, rather more work, but it's certainly a 
valid option, and really, truer to the Gentoo norm of the user 
controlling as much as possible (while still automated) of the installed 
software, including the CFLAGS used to compile it and the dependencies 
(USE flags) it builds against.  Multilib, while much less work, is both 
more complex to implement and much less under installed system sysadmin 
control.

The main point in bringing up the 32-bit chroot option here, however, is 
to note that rejecting multilib doesn't /necessarily/ mean rejecting 32-
bit on the system.  Rather, multilib is the middle ground between no 
32-bit support (no-multilib profile without the 32-bit chroot) and the 
full 32-bit chroot option with all the trimmings.

Meanwhile, no-multilib has some serious benefits, regardless of whether 
you do the 32-bit chroot or not.  Multilib being as it is, a mainly 64-
bit system with 32-bit add-ons arranged to allow 32-bit to work as well 
as possible under the circumstances, it involves a number of compromises 
and is quite complex, complicating the system considerably.  Regardless 
of whether one is keeping the 32-bit and 64-bit sides more cleanly 
separated by choosing a full 32-bit chroot on the one hand, or has 
decided they can do without 32-bit in general on the other, the result of 
choosing the no-multilib profile is a much cleaner layout, because the 64-
bit side doesn't have to worry about 32-bit at all (with the single 
exception of the kernel's 32-bit emulation option).  No double-compiling 
both the 32-bit and 64-bit parts of gcc or glibc in the same package 
means broken 32-bit can't block the successful completion and 
installation of the 64-bit package.  From my experience, that alone is 
the biggest problem people have with those packages on multilib profiles, 
and a gcc or glibc that can't be upgraded is a HUGE problem that can be a 
lot of hassle to solve, so eliminating the single biggest cause of that 
is a BIG deal!  No ld having both 32-bit and 64-bit library search paths 
to worry about and maintain, etc.  Less complexity and removing the 
single biggest cause of broken gccs translates directly to less hassle 
maintaining your installation. =:^)

As always, it's your system, so the decision is ultimately yours.  
There's serious tradeoffs, benefits and drawbacks to either multilib or 
nomultilib, 32-bit chroot or not, and no single solution is going to be 
best for everybody, but given a reasonable understanding of the benefits 
and drawbacks of each, most Gentoo/amd64 users should have little problem 
deciding what's best for their particular situation, based on just how 
much 32-bit they use and whether they prefer the less complex but more 
powerful 32-bit chroot or the less hassle multilib, should they decide 
they need to keep 32-bit support.  Most but not all 32-bit-only programs 
are available only as binary-only proprietaryware, so how much of that 
you may use plays the biggest part in whether you need 32-bit or not, but 
there's still the occasional open source program that hasn't been ported 
yet, and of course for some usage, in-house-only apps that may not have 
been ported, and these may play some albeit increasingly small part in 
the consideration as well.

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