[gentoo-amd64] Re: About to install on a 64 bit system. Advice wanted.

[Duncan]

Dale posted on Wed, 08 Dec 2010 18:26:00 -0600 as excerpted:

> Frank Peters wrote:
>> On Wed, 08 Dec 2010 15:17:18 -0600
>> Dale<rdalek1967@×××××.com>  wrote:
>>
>>> What are some things that I should watch for and enable that isn't so
>>> obvious for someone new to 64 bit?
>>>
>> The first thing to decide is whether or not you want a pure 64-bit
>> system or a 64-bit system that keeps 32-bit capability.
>>
>> I am a purist.  I left 32-bit programs in the dust a long time ago. But
>> as a consequence there are some things that I will miss because they
>> are available in 32-bit packages only.

> Now I have a question.  How do I tell Gentoo to make it pure 64 or a mix
> of 32 and 64?  I have read about this but I don't think I have actually
> seen where it is set.  Is it a profile selection, USE flag or something
> else?
>
> If I decide on one then want to switch to the other, does that require a
> reinstall or just a change in settings and a recompile of world?
>
> Since I use KDE, I always use Okular to view pdf files.  I assume KDE is
> 64 bit ready.

Welcome to 64-bit, Dale! (We both post follow a couple kde lists as well 
as certain other gentoo lists, and kde is definitely 64-bit ready, as I 
too run a 64-bit-only profile. =:^)

Frank had my thought, but of course my posts tend to beat details to 
death, so here goes...

First thing, know that an amd64 (aka x86_64, including Intel and Via 64-
bit x86, NOT just AMD) system can run either 32-bit or 64-bit in hardware, 
natively.  Which you decide to do for your system is your decision -- on 
Gentoo, you can build and run from x86 (32-bit) profiles or amd64 (64-bit) 
profiles.  If you run 64-bit/amd64, you have a second choice, multilib, 
which makes running 32-bit programs on a normally 64-bit profile easy, or 
no-multilib, profiles that are 64-bit only.  Both Frank and I have chosen 
the no-multilib profile.

However, note that it's still possible to do a 32-bit x86 profile chroot 
build on an otherwise amd64 no-multilib profile machine, it's just more 
work, as now you're effectively building much of the system twice, once 
for amd64 no-multilib and once for the x86 chroot.  However, despite the 
extra work, in some ways this is closer to what some might call the pure 
"Gentoo way", because it remains the only way to build /everything/ from 
source, both 32-bit and 64-bit.  (Multilib uses pre-built 32-bit binaries, 
emul-linux-86x-* packages for many libraries and *-bin, example firefox-
bin, for selected 32-bit binaries, while building only 64-bit for most 
stuff.  However, multilib does build 32-bit and 64-bit for a few critical 
toolchain packages like the glibc system library, gcc, portage's sandbox, 
etc.)  There's a couple reasons you might want to do this, as covered 
below.

Which you may /want/ to run is an interesting question.  Certainly, 32-bit 
is most compatible with as Frank says, generally legacy and mostly closed 
source software.  On archs other than x86 (ppc, mips, etc), there's often 
a definite advantage to staying 32-bit, except for perhaps the kernel 
itself and maybe one or two really huge memory sucking things like 
databases and their dependencies, because 32-bit code is smaller (memory 
addresses double their size to 64-bit on 64-bit) and there's little 
instruction-set difference between the bitness variants of the arch, so 32-
bit userspace conserves memory and is simpler. Still, once one gets to 4 
gig of RAM, a 64-bit kernel is preferred (even tho, on Linux x86 at least, 
a 32-bit kernel can make use of upto 64 gig of RAM, at significant loss of 
efficiency), and similarly, once apps (like big databases) start using 
gigs of memory for a single app, it's time to go 64-bit.  Thus, it's 
common on other archs (and an option, tho not fully supported, on gentoo/
amd64) to have a 64-bit kernel, 32-bit userspace, profile, as well as full 
32-bit and full 64-bit kernel and userspace.

However, on x86, the 32-bit instruction-set has a number of weaknesses, 
chief among them being an extremely limited set of available CPU 
registers, that the 64-bit instruction set corrects -- there are many more 
available registers in 64-bit mode.  For this reason, on x86, the ordinary 
negatives of going full 64-bit are reasonably balanced out by the 
positives of the less limited instruction set, with the result being that 
the 64-bit kernel-space, 32-bit userland model is *FAR* less common.  As I 
said, there's an option (profile) available for it on Gentoo, but it's not 
considered supported.  Most folks go either full 64-bit (tho with multilib, 
which is supported and in fact the Gentoo default) or stay with 32-bit 
only.

So your first choice is whether you want to stick with a standard 32-bit-
only x86 install on your new 64-bit-capable system, or whether you're 
ready to go 64-bit.  Presumably, you'll go 64-bit kernel /and/ userland, 
and that's what the rest of this post assumes.

With that decision out of the way, one now has to decide between a multilib 
and a no-multilib profile.  A multilib profile is the default, but both 
Frank and I have chosen no-multilib as we prefer full 64-bit systems 
without the complications of the 32-bit multilib, and we don't have apps 
that require 32-bit compatibility be maintained.  (I won't speak for 
Frank, but I'm sure from seeing my posts in the kde lists and elsewhere 
that you know I cannot and will-not install servantware, in the context of 
my sig.  Since binary-only servantware is what most of the remaining 32-
bit only Linux software is, and I cannot and will not install it, that 
leaves me far freer to consider a no-multilib profile, as I'm not bound to 
some old 32-bit-binary-only software like some servant bound to his 
master.  My choices are mine and I'm /not/ telling you what to do -- 
that's your decision, but at the same time, my feelings are quite strong 
on the subject and you're reading my post -- they come with the territory.)

As I said, multilib is the Gentoo default, in part because the same 
multilib-based stages can be used to build both multilib and no-multilib 
systems, depending on the profile chosen.  As long as the system is 
multilib, you have the choice of switching profiles, rebuilding, and going 
nomultilib, but once you've switched to nomultilib and rebuild the 
toolchain (gcc, glibc, etc), it loses the capacity to build the 32-bit 
side, and the only (easy, well, "easy" in relative terms) way back to 
multilib is to start with a new multilib stage tarball and rebuild.  So in 
that regard, going no-multilib is a one-way decision.  You can make it at 
any time as long as you are still multilib, but once no-multilib, you 
can't so easily go back.

That said, there /are/ certain complexities and negatives to multilib.  
One is simply the time involved to build already long-build toolchain 
packages, glibc and gcc especially, since effectively you're building them 
twice, once for 32-bit and once for 64-bit.  Another is the previously 
mentioned not-quite-the-normal-gentoo-way of multilib, with all the pre-
built binaries of emul-linux-x86-* (for libs) and *-bin (for 
executables).  Those builds by definition have way more generic CFLAGS, 
USE flags, etc, than what one may well have if they built them from source.

Third, due to its complexity, multilib is somewhat brittle, and because 
most stuff builds as 64-bit only, it's possible for the 32-bit toolchain 
side to break and remain broken for some time before its detected, then 
you suddenly find yourself without an easy way to upgrade your toolchain 
(glibc, gcc, sandbox, binutils, for the most part), since multilib will 
try to build both, and the 32-bit side is broken.  Not to scare you as 
multilib *IS* supported and there are (semi-complex, sometimes involving 
extracting files or whole packages from a stage tarball -- 
FEATURES=buildpkg can help avoid that, BTW) ways out of this bind, that 
people can help you with if you find yourself in this situation, and 
certainly, the on-the-edge ~amd64 and sometimes still hard-masked-for-
testing stuff that I tend to run made me more susceptible to this than 
many, but it was after about the third time of having this happen to me, 
that I decided, since I didn't need 32-bit compatibility anyway, I might 
as well do away with the headache and go full no-multilib.  That was 
definitely one of my better decisions; one I've certainly not regretted.  
Since then I've appreciated both the lower-complexity/better-robustness 
and the faster build-times of no-multilib, and as I said, since I don't 
run the servantware that tends to be about the only software left that's 
32-bit only, there wasn't any compatibility issues at all to worry about, 
here.

Meanwhile, what about that 32-bit chroot option I mentioned?  Actually, 
there's a whole properly documented Gentoo guide for that, and it's sort 
of special case, so I'll skip the details on it, but I'll describe enough 
about it so you have some idea why you might want to run one and how it 
works.

As it happens, I do actually run one here, tho not for the normal reason, 
better 32-bit compatibility.  Rather, I have a 32-bit-only Atom based 
netbook that I run Gentoo on as well.  But my 64-bit system is 
sufficiently beefier than the Atom, that I saw no reason to have that puny 
single-core Atom with only a gig and a half of memory and a single drive 
toiling away for days to build its system or update, say KDE, when I could 
do the same thing in hours, on a 32-bit chroot build-image on my main 
machine.  So that's what I use the 32-bit chroot for, as the build-image 
for my Atom based netbook.  I have a custom scripted SSH and rsync setup 
to keep the necessary parts of the two systems synced (the netbook doesn't 
even have a portage tree on it, I mount it into the chroot on my main 
machine, tho I do keep the package database on both the build image and 
the netbook, for backup purposes), and the 32-bit chroot build image on 
the main machine is the way I handled building and now handle updates on 
my Gentoo based netbook. =:^)

But whether you use it for something like that, or need better or more 
proper "gentoo-like" 32-bit support than multilib gives you, the basic 
idea is that you setup a chroot, unpack a normal 32-bit x86 tarball onto 
it, selectively mount parts of your main 64-bit system into the chroot, 
and then build /most/ of a 32-bit system as you normally would.  If you're 
using it as a build-image for another system, as I do, you build stuff 
like syslog, cron, an appropriate 32-bit kernel, etc, too.  But if you're 
only using it for better 32-bit support than multilib gives you on your 
main 64-bit system, you can skip stuff like that, since the 32-bit chroot 
still uses the system kernel and services from its 64-bit host.

If you /do/ decide to run a 32-bit chroot, it takes care of the 32-bit 
compatibility stuff better than multilib does, so running no-multilib on 
the main system makes sense.  One /possible/ exception to that might be 
the servantware graphics drivers, since on a multilib system they'll build 
both 32-bit and 64-bit interfaces and must be built against the system 
kernel.  Gamers in particular may be concerned about that.  However, I'm 
unsure of that, since as already mentioned, servantware including 
servantware graphics drivers isn't a viable option for me, so others are 
certainly better qualified to answer questions in that area if it's a 
concern.

Finally, to answer your multilib question directly, it's a profile 
setting.  Once you are setting up your 64-bit system, have the stage 
tarball installed, and get to the point of selecting your profile, eselect 
profile list should do just that, list available profile choices, 
including no-multilib.  For reference, here's what I get listed here, with 
the no-multilib option starred, indicating it's active.  (Note that as 
I've been no-multilib for some time and no longer have a multilib 
toolchain, most of these aren't viable options for me after all, but this 
is the list a fresh installing user might be able to choose.)

$ eselect profile list
Available profile symlink targets:
  [1]   default/linux/amd64/10.0
  [2]   default/linux/amd64/10.0/desktop
  [3]   default/linux/amd64/10.0/desktop/gnome
  [4]   default/linux/amd64/10.0/desktop/kde
  [5]   default/linux/amd64/10.0/developer
  [6]   default/linux/amd64/10.0/no-multilib *
  [7]   default/linux/amd64/10.0/server
  [8]   hardened/linux/amd64
  [9]   hardened/linux/amd64/no-multilib
  [10]  selinux/2007.0/amd64
  [11]  selinux/2007.0/amd64/hardened
  [12]  selinux/v2refpolicy/amd64
  [13]  selinux/v2refpolicy/amd64/desktop
  [14]  selinux/v2refpolicy/amd64/developer
  [15]  selinux/v2refpolicy/amd64/hardened
  [16]  selinux/v2refpolicy/amd64/server
$ 

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