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