1 |
Allan Spagnol Comar posted |
2 |
<1cc2dc830604240812r599a7aefw652004ac34827092@××××××××××.com>, excerpted |
3 |
below, on Mon, 24 Apr 2006 12:12:08 -0300: |
4 |
|
5 |
> Hi all, Thanks for all the advises !!! |
6 |
> |
7 |
> I will try run some binary 32 bits programs ( until now I was using |
8 |
> just source programs ) |
9 |
> |
10 |
> I got curious with chroot enviroments, is there any literature that I |
11 |
> can find ( like manuals and samples, I am newbee speaking of cross or |
12 |
> dual platforms ). |
13 |
|
14 |
I thought it might be this thread I posted all the Gentoo URLs too. It |
15 |
wasn't. However, you are in luck, because Gentoo is known for the quality |
16 |
of its documentation, and Gentoo for AMD64 has a decent collection of its |
17 |
own on our hardware, including one specifically on setting up chroots for |
18 |
32-bit on a 64-bit platform. =8^) Listed below. |
19 |
|
20 |
> Duncan, you real are a little radical but I like some of your |
21 |
> thoughts, one thing that make me curious it will be about the |
22 |
> advantages of using a gentoo x86 on a AMD64, once I would not be able |
23 |
> to make optimizations on compilation flags ? |
24 |
|
25 |
You have actually three choices, here, all sticking with Gentoo, only one |
26 |
of which doesn't allow you to manage CFLAGS and the like in 32-bit mode. |
27 |
=8^) |
28 |
|
29 |
A basic rule of multilib is that trying to load a 32-bit library |
30 |
in a 64-bit program cannot and will not work. (The reverse is also true, |
31 |
32-bit programs can't /normally/ load 64-bit shared objects into their |
32 |
execution space. Games are the major example here.) The problem is that |
33 |
all these binary-only slaverywares, mostly codecs and browser plugins, are |
34 |
available for Linux in 32-bit binary-blob-only shared objects (*.so, the |
35 |
Linux equivalent of the MS platforms' DLLs). They are designed to be |
36 |
loaded into 32-bit browsers and 32-bit media players. They simply won't |
37 |
work in the 64-bit equivalents. |
38 |
|
39 |
That's the problem. As I said, there are three solutions available for it |
40 |
within the Gentoo system. |
41 |
|
42 |
Option One: |
43 |
|
44 |
For those who don't run a lot of 32-bit stuff, and don't care so much |
45 |
about 32-bit optimization, there's the default multilib setup that most of |
46 |
us run. Selected apps, among them firefox (covering the 32-bit browser |
47 |
plugin problem) and mplayer (for the 32-bit codecs) are available |
48 |
precompiled, as firefox-bin and mplayer-bin. Likewise, the most |
49 |
frequently needed 32-bit libraries are available in 32-bit binary |
50 |
compatibility packages. There's a list in one of the documents below, but |
51 |
for games and etc. with ebuilds, the dependencies are taken care of by |
52 |
portage as usual. The list, therefore, is mostly in case you run the game |
53 |
installers or compile your own 32-bit programs outside of portage. |
54 |
|
55 |
That's the non-optimized choice -- you trade the ability to optimize for |
56 |
the convenience of the pre-built binary packages. Note that the |
57 |
non-optimized qualifier only applies to the 32-bit compatibility stuff. |
58 |
The 64-bit side of your system is handled as usual in Gentoo, as you are |
59 |
likely already aware since you've been running it and getting frustrated |
60 |
with the 32-bit problems, since you didn't understand them. =8^( |
61 |
|
62 |
Option Two: |
63 |
|
64 |
The first optimized choice is the chroot option. Again, your system is |
65 |
64-bit in general, but you run a 32-bit chroot that's almost (but not |
66 |
quite, you don't need 32-bit sysloggers or kernels for example as the |
67 |
64-bit side provides those) an entire Gentoo x86 system on its own. In |
68 |
this chroot, you run a second version of portage, that doesn't know about |
69 |
the 64-bit side, only its 32-bit stuff. It tracks all your 32-bit |
70 |
dependencies just like portage normally does for a system. You configure |
71 |
this chroot version of portage with all the usual optimization stuff, |
72 |
CFLAGS and the like, you'd normally use on a 32-bit x86 system. From |
73 |
inside the chroot, the system looks just like a normal 32-bit system, only |
74 |
missing the system service packages (like your syslogger) provided by the |
75 |
64-bit side. You want to run a 32-bit KDE installation? Merge it. |
76 |
Gnome? Merge that. With a bit of remount trickery, you can expose the |
77 |
same /tmp and /home partitions (and the portage tree if you have it on its |
78 |
own partition) for both the 32-bit chroot and the 64-bit main system. |
79 |
This lets the 32-bit stuff see the X sockets and the like in /tmp, and |
80 |
gives you access to the same /home dir and personal login settings on |
81 |
both sides. The chroot of course has its own root, inside the main system |
82 |
root, as that's how a chroot works. /usr and /var likewise remain |
83 |
separate. |
84 |
|
85 |
Keep in mind, however, that the chroot is normally only needed for |
86 |
compiling stuff -- it's where the 32-bit only aware version of portage |
87 |
runs. You then add the 32-bit bin paths and 32-bit LDPATHs to your main |
88 |
system configuration, and when properly configured, you can then run |
89 |
binaries from either the chroot or the 64-bit main system alike -- the |
90 |
32-bit binaries can't load the 64-bit libraries anyway, and don't try. |
91 |
The 64-bit binaries likewise, only load the 64-bit shared objects. |
92 |
|
93 |
What happens if you have both a 32-bit and a 64-bit firefox (for example)? |
94 |
Which one does the system run? Easy. If you don't type in the path, |
95 |
only typing "firefox", it runs the one located in the directory that |
96 |
appears first in your path. If you want 32-bit as the default, set it |
97 |
first in your path. 64-bit? Set that first. To run the other one, you |
98 |
simply use the full path, /usr/bin/firefox or whatever. |
99 |
|
100 |
The chroot doc has more info, but the key thing to remember about chroot |
101 |
is that it's most useful for those doing enough 32-bit stuff to make the |
102 |
additional hassle of running and keeping uptodate almost an entire second |
103 |
system worth the trouble. You can compile by hand individual |
104 |
32-bit packages using multilib, but portage can't handle the deps (except |
105 |
for its binary compatibility packages, which are tracked separately from |
106 |
the regular from-source versions) of both 32-bit and 64-bit at the same |
107 |
time, so if you are compiling enough to make tracking the deps manually a |
108 |
big headache, or if you want fully optimized 32-bit stuff and don't want |
109 |
to do it manually, the chroot is the way to go. More work to keep up both |
110 |
the main system and the chroot, but you get both systems fully optimized |
111 |
as you wish. |
112 |
|
113 |
Option Three: |
114 |
|
115 |
The third choice is the one that I was recommending you consider, in the |
116 |
previous reply, based on the problems you mentioned. If 64-bit is too |
117 |
much hassle but you like Gentoo, simply stick with it, and put 32-bit |
118 |
Gentoo on your system, instead of 64-bit. You do lose a bit of |
119 |
optimization possible in 64-bit mode, but the AMD64 platform makes a very |
120 |
good 32-bit platform as well, and 32-bit stuff runs on it every bit as |
121 |
fast (often faster, because AMD64 is very good even in 32-bit only mode) |
122 |
as it would run on any other 32-bit system. |
123 |
|
124 |
The idea here is that you pretend your AMD64 is a regular x86, forgetting |
125 |
about 64-bit altogether (at least for now, you can always decide to try it |
126 |
again in a year or two), and download a regular athlon/x86 stage and |
127 |
install from that, instead of using the amd64 stages. Your keywords are |
128 |
x86 or ~x86, not amd64 or ~amd64. You run a 32-bit gcc and a 32-bit |
129 |
distribution in every sense of the word. The hardware is still 64-bit, |
130 |
but you are running a full 32-bit Linux system on it, no 64-bit software |
131 |
at all. |
132 |
|
133 |
The reason I think this fits your needs is because you said you liked |
134 |
Gentoo for x86, and were just tired of all the hassles of Gentoo for |
135 |
AMD64. You were thinking about running another distribution, a binary |
136 |
one. That's definitely an option available, but it doesn't to me sound |
137 |
like one you'll be happy with, because you like Gentoo, you just don't |
138 |
like the AMD64 hassles. So get rid of the amd64 hassles and just install |
139 |
a 32-bit Gentoo on the system! There's nothing saying you can't do that, |
140 |
and in fact, AMD specifically designed AMD64s for that possibility. Keep |
141 |
in mind that in the MSWormOS world, most folks were running a standard |
142 |
32-bit MSWormOS on their 64-bit system for quite awhile, because MS was |
143 |
much slower in making a 64-bit OS available than Linux was! |
144 |
|
145 |
This list deals with the AMD64 Gentoo, so if you went regular 32-bit only, |
146 |
you'd probably find little of the discussion here of interest. You'd use |
147 |
the regular forums and user list, just as every other x86 Gentoo user |
148 |
does. Likewise, the docs I'm about to list apply to Gentoo for AMD64, not |
149 |
Gentoo for x86, so if you choose this option, feel free to ignore them. |
150 |
Your installation will be x86 Gentoo in every sense of the term, just like |
151 |
the other x86 Gentoo systems you've run in the past. |
152 |
|
153 |
The docs list: |
154 |
|
155 |
Here's a list of docs for Gentoo AMD64 that should help. Of particular |
156 |
interest will be the FAQ, which should provide a bit more help deciding |
157 |
which of the above options is for you (tho I don't believe it deals with |
158 |
the x86-only option), and the chroot guide, which will give you a much |
159 |
better idea of how that works, and if you choose that option, guide you |
160 |
thru setting it up. |
161 |
|
162 |
Gentoo AMD64 FAQ |
163 |
http://www.gentoo.org/doc/en/gentoo-amd64-faq.xml |
164 |
|
165 |
32-bit chroot Guide for Gentoo/AMD64 |
166 |
http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=2 |
167 |
|
168 |
Creating 32-bit Packages for Gentoo AMD64 |
169 |
(This is a user page, not an official Gentoo page. It probably won't be |
170 |
useful to you right now, but it's an interesting read, particularly if you |
171 |
already have a chroot setup.) |
172 |
http://www.andyjeffries.co.uk/32bit-ebuild-amd64.html |
173 |
|
174 |
One of the devs created a script that automates part of the chroot stuff, |
175 |
if you want to go that route. I don't believe it's officially supported, |
176 |
and Travis Tilley's dev page is no longer there (IIRC he moved on to |
177 |
other pursuits and is no longer a Gentoo dev) but here's the links to it |
178 |
and the docs, as mirrored. Note that these are hosted by the same guy who |
179 |
wrote the 32-bit packages doc, above: |
180 |
Script: |
181 |
http://www.andyjeffries.co.uk/32bit/setup-gentoo-chroot |
182 |
Docs: |
183 |
http://www.andyjeffries.co.uk/32bit/chrootthingiehowto |
184 |
|
185 |
The old, deprecated Technotes. |
186 |
(This has been replaced by the FAQ, but it's still useful as a historical |
187 |
reference, and because it covers most of the same stuff as the FAQ, but in |
188 |
a different way. Sometimes reading the same thing put two different ways |
189 |
helps one understand it, so the technotes remain useful in that regard.) |
190 |
http://www.gentoo.org/proj/en/base/amd64/technotes/index.xml |
191 |
|
192 |
Hope all that helps, and may your choice be a pleasant one! =8^) |
193 |
|
194 |
-- |
195 |
Duncan - List replies preferred. No HTML msgs. |
196 |
"Every nonfree program has a lord, a master -- |
197 |
and if you use the program, he is your master." Richard Stallman in |
198 |
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
199 |
|
200 |
|
201 |
-- |
202 |
gentoo-amd64@g.o mailing list |