Gentoo Archives: gentoo-amd64

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-amd64@l.g.o
Subject: [gentoo-amd64] Re: About to install on a 64 bit system. Advice wanted.
Date: Thu, 09 Dec 2010 05:06:58
In Reply to: Re: [gentoo-amd64] About to install on a 64 bit system. Advice wanted. by Dale
1 Dale posted on Wed, 08 Dec 2010 18:26:00 -0600 as excerpted:
3 > Frank Peters wrote:
4 >> On Wed, 08 Dec 2010 15:17:18 -0600
5 >> Dale<rdalek1967@×××××.com> wrote:
6 >>
7 >>> What are some things that I should watch for and enable that isn't so
8 >>> obvious for someone new to 64 bit?
9 >>>
10 >> The first thing to decide is whether or not you want a pure 64-bit
11 >> system or a 64-bit system that keeps 32-bit capability.
12 >>
13 >> I am a purist. I left 32-bit programs in the dust a long time ago. But
14 >> as a consequence there are some things that I will miss because they
15 >> are available in 32-bit packages only.
17 > Now I have a question. How do I tell Gentoo to make it pure 64 or a mix
18 > of 32 and 64? I have read about this but I don't think I have actually
19 > seen where it is set. Is it a profile selection, USE flag or something
20 > else?
21 >
22 > If I decide on one then want to switch to the other, does that require a
23 > reinstall or just a change in settings and a recompile of world?
24 >
25 > Since I use KDE, I always use Okular to view pdf files. I assume KDE is
26 > 64 bit ready.
28 Welcome to 64-bit, Dale! (We both post follow a couple kde lists as well
29 as certain other gentoo lists, and kde is definitely 64-bit ready, as I
30 too run a 64-bit-only profile. =:^)
32 Frank had my thought, but of course my posts tend to beat details to
33 death, so here goes...
35 First thing, know that an amd64 (aka x86_64, including Intel and Via 64-
36 bit x86, NOT just AMD) system can run either 32-bit or 64-bit in hardware,
37 natively. Which you decide to do for your system is your decision -- on
38 Gentoo, you can build and run from x86 (32-bit) profiles or amd64 (64-bit)
39 profiles. If you run 64-bit/amd64, you have a second choice, multilib,
40 which makes running 32-bit programs on a normally 64-bit profile easy, or
41 no-multilib, profiles that are 64-bit only. Both Frank and I have chosen
42 the no-multilib profile.
44 However, note that it's still possible to do a 32-bit x86 profile chroot
45 build on an otherwise amd64 no-multilib profile machine, it's just more
46 work, as now you're effectively building much of the system twice, once
47 for amd64 no-multilib and once for the x86 chroot. However, despite the
48 extra work, in some ways this is closer to what some might call the pure
49 "Gentoo way", because it remains the only way to build /everything/ from
50 source, both 32-bit and 64-bit. (Multilib uses pre-built 32-bit binaries,
51 emul-linux-86x-* packages for many libraries and *-bin, example firefox-
52 bin, for selected 32-bit binaries, while building only 64-bit for most
53 stuff. However, multilib does build 32-bit and 64-bit for a few critical
54 toolchain packages like the glibc system library, gcc, portage's sandbox,
55 etc.) There's a couple reasons you might want to do this, as covered
56 below.
58 Which you may /want/ to run is an interesting question. Certainly, 32-bit
59 is most compatible with as Frank says, generally legacy and mostly closed
60 source software. On archs other than x86 (ppc, mips, etc), there's often
61 a definite advantage to staying 32-bit, except for perhaps the kernel
62 itself and maybe one or two really huge memory sucking things like
63 databases and their dependencies, because 32-bit code is smaller (memory
64 addresses double their size to 64-bit on 64-bit) and there's little
65 instruction-set difference between the bitness variants of the arch, so 32-
66 bit userspace conserves memory and is simpler. Still, once one gets to 4
67 gig of RAM, a 64-bit kernel is preferred (even tho, on Linux x86 at least,
68 a 32-bit kernel can make use of upto 64 gig of RAM, at significant loss of
69 efficiency), and similarly, once apps (like big databases) start using
70 gigs of memory for a single app, it's time to go 64-bit. Thus, it's
71 common on other archs (and an option, tho not fully supported, on gentoo/
72 amd64) to have a 64-bit kernel, 32-bit userspace, profile, as well as full
73 32-bit and full 64-bit kernel and userspace.
75 However, on x86, the 32-bit instruction-set has a number of weaknesses,
76 chief among them being an extremely limited set of available CPU
77 registers, that the 64-bit instruction set corrects -- there are many more
78 available registers in 64-bit mode. For this reason, on x86, the ordinary
79 negatives of going full 64-bit are reasonably balanced out by the
80 positives of the less limited instruction set, with the result being that
81 the 64-bit kernel-space, 32-bit userland model is *FAR* less common. As I
82 said, there's an option (profile) available for it on Gentoo, but it's not
83 considered supported. Most folks go either full 64-bit (tho with multilib,
84 which is supported and in fact the Gentoo default) or stay with 32-bit
85 only.
87 So your first choice is whether you want to stick with a standard 32-bit-
88 only x86 install on your new 64-bit-capable system, or whether you're
89 ready to go 64-bit. Presumably, you'll go 64-bit kernel /and/ userland,
90 and that's what the rest of this post assumes.
92 With that decision out of the way, one now has to decide between a multilib
93 and a no-multilib profile. A multilib profile is the default, but both
94 Frank and I have chosen no-multilib as we prefer full 64-bit systems
95 without the complications of the 32-bit multilib, and we don't have apps
96 that require 32-bit compatibility be maintained. (I won't speak for
97 Frank, but I'm sure from seeing my posts in the kde lists and elsewhere
98 that you know I cannot and will-not install servantware, in the context of
99 my sig. Since binary-only servantware is what most of the remaining 32-
100 bit only Linux software is, and I cannot and will not install it, that
101 leaves me far freer to consider a no-multilib profile, as I'm not bound to
102 some old 32-bit-binary-only software like some servant bound to his
103 master. My choices are mine and I'm /not/ telling you what to do --
104 that's your decision, but at the same time, my feelings are quite strong
105 on the subject and you're reading my post -- they come with the territory.)
107 As I said, multilib is the Gentoo default, in part because the same
108 multilib-based stages can be used to build both multilib and no-multilib
109 systems, depending on the profile chosen. As long as the system is
110 multilib, you have the choice of switching profiles, rebuilding, and going
111 nomultilib, but once you've switched to nomultilib and rebuild the
112 toolchain (gcc, glibc, etc), it loses the capacity to build the 32-bit
113 side, and the only (easy, well, "easy" in relative terms) way back to
114 multilib is to start with a new multilib stage tarball and rebuild. So in
115 that regard, going no-multilib is a one-way decision. You can make it at
116 any time as long as you are still multilib, but once no-multilib, you
117 can't so easily go back.
119 That said, there /are/ certain complexities and negatives to multilib.
120 One is simply the time involved to build already long-build toolchain
121 packages, glibc and gcc especially, since effectively you're building them
122 twice, once for 32-bit and once for 64-bit. Another is the previously
123 mentioned not-quite-the-normal-gentoo-way of multilib, with all the pre-
124 built binaries of emul-linux-x86-* (for libs) and *-bin (for
125 executables). Those builds by definition have way more generic CFLAGS,
126 USE flags, etc, than what one may well have if they built them from source.
128 Third, due to its complexity, multilib is somewhat brittle, and because
129 most stuff builds as 64-bit only, it's possible for the 32-bit toolchain
130 side to break and remain broken for some time before its detected, then
131 you suddenly find yourself without an easy way to upgrade your toolchain
132 (glibc, gcc, sandbox, binutils, for the most part), since multilib will
133 try to build both, and the 32-bit side is broken. Not to scare you as
134 multilib *IS* supported and there are (semi-complex, sometimes involving
135 extracting files or whole packages from a stage tarball --
136 FEATURES=buildpkg can help avoid that, BTW) ways out of this bind, that
137 people can help you with if you find yourself in this situation, and
138 certainly, the on-the-edge ~amd64 and sometimes still hard-masked-for-
139 testing stuff that I tend to run made me more susceptible to this than
140 many, but it was after about the third time of having this happen to me,
141 that I decided, since I didn't need 32-bit compatibility anyway, I might
142 as well do away with the headache and go full no-multilib. That was
143 definitely one of my better decisions; one I've certainly not regretted.
144 Since then I've appreciated both the lower-complexity/better-robustness
145 and the faster build-times of no-multilib, and as I said, since I don't
146 run the servantware that tends to be about the only software left that's
147 32-bit only, there wasn't any compatibility issues at all to worry about,
148 here.
150 Meanwhile, what about that 32-bit chroot option I mentioned? Actually,
151 there's a whole properly documented Gentoo guide for that, and it's sort
152 of special case, so I'll skip the details on it, but I'll describe enough
153 about it so you have some idea why you might want to run one and how it
154 works.
156 As it happens, I do actually run one here, tho not for the normal reason,
157 better 32-bit compatibility. Rather, I have a 32-bit-only Atom based
158 netbook that I run Gentoo on as well. But my 64-bit system is
159 sufficiently beefier than the Atom, that I saw no reason to have that puny
160 single-core Atom with only a gig and a half of memory and a single drive
161 toiling away for days to build its system or update, say KDE, when I could
162 do the same thing in hours, on a 32-bit chroot build-image on my main
163 machine. So that's what I use the 32-bit chroot for, as the build-image
164 for my Atom based netbook. I have a custom scripted SSH and rsync setup
165 to keep the necessary parts of the two systems synced (the netbook doesn't
166 even have a portage tree on it, I mount it into the chroot on my main
167 machine, tho I do keep the package database on both the build image and
168 the netbook, for backup purposes), and the 32-bit chroot build image on
169 the main machine is the way I handled building and now handle updates on
170 my Gentoo based netbook. =:^)
172 But whether you use it for something like that, or need better or more
173 proper "gentoo-like" 32-bit support than multilib gives you, the basic
174 idea is that you setup a chroot, unpack a normal 32-bit x86 tarball onto
175 it, selectively mount parts of your main 64-bit system into the chroot,
176 and then build /most/ of a 32-bit system as you normally would. If you're
177 using it as a build-image for another system, as I do, you build stuff
178 like syslog, cron, an appropriate 32-bit kernel, etc, too. But if you're
179 only using it for better 32-bit support than multilib gives you on your
180 main 64-bit system, you can skip stuff like that, since the 32-bit chroot
181 still uses the system kernel and services from its 64-bit host.
183 If you /do/ decide to run a 32-bit chroot, it takes care of the 32-bit
184 compatibility stuff better than multilib does, so running no-multilib on
185 the main system makes sense. One /possible/ exception to that might be
186 the servantware graphics drivers, since on a multilib system they'll build
187 both 32-bit and 64-bit interfaces and must be built against the system
188 kernel. Gamers in particular may be concerned about that. However, I'm
189 unsure of that, since as already mentioned, servantware including
190 servantware graphics drivers isn't a viable option for me, so others are
191 certainly better qualified to answer questions in that area if it's a
192 concern.
194 Finally, to answer your multilib question directly, it's a profile
195 setting. Once you are setting up your 64-bit system, have the stage
196 tarball installed, and get to the point of selecting your profile, eselect
197 profile list should do just that, list available profile choices,
198 including no-multilib. For reference, here's what I get listed here, with
199 the no-multilib option starred, indicating it's active. (Note that as
200 I've been no-multilib for some time and no longer have a multilib
201 toolchain, most of these aren't viable options for me after all, but this
202 is the list a fresh installing user might be able to choose.)
204 $ eselect profile list
205 Available profile symlink targets:
206 [1] default/linux/amd64/10.0
207 [2] default/linux/amd64/10.0/desktop
208 [3] default/linux/amd64/10.0/desktop/gnome
209 [4] default/linux/amd64/10.0/desktop/kde
210 [5] default/linux/amd64/10.0/developer
211 [6] default/linux/amd64/10.0/no-multilib *
212 [7] default/linux/amd64/10.0/server
213 [8] hardened/linux/amd64
214 [9] hardened/linux/amd64/no-multilib
215 [10] selinux/2007.0/amd64
216 [11] selinux/2007.0/amd64/hardened
217 [12] selinux/v2refpolicy/amd64
218 [13] selinux/v2refpolicy/amd64/desktop
219 [14] selinux/v2refpolicy/amd64/developer
220 [15] selinux/v2refpolicy/amd64/hardened
221 [16] selinux/v2refpolicy/amd64/server
222 $
224 --
225 Duncan - List replies preferred. No HTML msgs.
226 "Every nonfree program has a lord, a master --
227 and if you use the program, he is your master." Richard Stallman