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@gmail.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
