1 |
Mansour Al Akeel posted on Mon, 15 Mar 2010 15:04:49 -0300 as excerpted: |
2 |
|
3 |
> Hello Duncan: |
4 |
> Pleae read my comments. |
5 |
> |
6 |
> On Sat Mar 13,2010 10:20 pm, Duncan wrote: |
7 |
>> Volker Armin Hemmann posted on Sat, 13 Mar 2010 16:29:06 +0100 as |
8 |
>> excerpted: |
9 |
>> |
10 |
>> > On Samstag 13 M??rz 2010, Mansour Al Akeel wrote: |
11 |
>> >> Hello all, |
12 |
>> >> |
13 |
>> >> I have been looking into installing wine and a cross dev tool chain. |
14 |
>> >> I didn't get much luck, since I have amd64 and I use no-multilib. I |
15 |
>> >> found this http://bugs.gentoo.org/269439 and I am wondering if any |
16 |
>> >> one can provide an advice. Is it be possible to run wine on amd64 |
17 |
>> >> with no-multilib ? |
18 |
>> > |
19 |
>> > you won't be able to run any 32bit windows app. Which makes wine |
20 |
>> > pretty useless. |
21 |
>> |
22 |
>> FWIW, I have no-multilib, but with the 32-bit compatibility turned on |
23 |
>> in the kernel, I'm able to do the 32-bit chroot thing as in the |
24 |
>> gentoo/amd64 documentation. |
25 |
>> |
26 |
>> In my case, I'm doing a full 32-bit chroot image, which then gets |
27 |
>> transferred to my AA1 netbook. (The big machine has far more memory |
28 |
>> and power to do the compiles, so it makes more sense to do that and not |
29 |
>> even have the gentoo tree on the netbook, just transfer over the |
30 |
>> prebuilt, preconfigured image, and rsync it again after every update. |
31 |
>> I've never booted the 32-bit image on the big machine, tho, and indeed, |
32 |
>> couldn't, as the kernel drivers, etc, are all built-in and configured |
33 |
>> for the netbook.) |
34 |
> |
35 |
> Are you saying that you have another 32bit gentoo image, and you mount |
36 |
> it somewhere and chroot to it? If so, what does the memory has to do |
37 |
> with this ? Can you please elaborate on this ? The space is not a |
38 |
> concern to me, but I'd rather not mix 32 and 64 libs. |
39 |
|
40 |
Yes. I have a 32-bit chroot image that gets mounted and chrooted into |
41 |
(using linux32 chroot ...) as per the gentoo/amd64 32-bit chroot guide. |
42 |
That works just fine with no-multilib, and indeed, multilib would |
43 |
duplicate functionality to some degree. Just make sure your kernel has |
44 |
32-bit "emulation" turned on (tho it's not really emulation, in the same |
45 |
way that wine is not an emulator, amd64/x86_64 is true dual-bitness |
46 |
hardware). |
47 |
|
48 |
I posted the link to the guide in the doomsday thread pretty much |
49 |
concurrently to the discussion here, but for convenience, here's the link: |
50 |
|
51 |
http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=2 |
52 |
|
53 |
That explains the process and covers the step-by-step quite nicely. I |
54 |
discuss it in more depth in the doomsday thread, so I'd suggest you read |
55 |
it if you're seriously interested in this. Meanwhile... |
56 |
|
57 |
As mentioned, I use the 32-bit chroot for a somewhat different purpose, |
58 |
building a separate 32-bit image to run on my 32-bit-only netbook. As |
59 |
such, I have a fully configured and bootable build-out of the 32-bit as if |
60 |
it were an entirely separate machine, even if I never boot to it on this |
61 |
machine, because it is intended to run on a separate machine. However, |
62 |
while that's a reasonably trivial extension from the 32-bit chroot guide, |
63 |
it's not why it was written, nor what it directly addresses. But as you |
64 |
specify, it's definitely entirely separate, no mixed 32/64-bit as multilib |
65 |
does, or it'd be unsuitable for the 32-bit-only machine usage to which I |
66 |
put it. So rest assured on that point. The only mixing between the two |
67 |
systems are mount-binds setup to expose stuff like a common tempdir |
68 |
between the two systems (and of course that you happen to be running on a |
69 |
64-bit host kernel in the first place), and it's relatively trivial to |
70 |
simply not mount-bind what you specifically don't need. If you're |
71 |
familiar with chroots, mount-binds for access within the chroot are pretty |
72 |
standard stuff, and it /is/ a chroot, so it's as entirely separate as a |
73 |
chroot normally would be. |
74 |
|
75 |
As to your specific question "what does the memory have to do with this?", |
76 |
I don't quite understand the question, so pardon my not answering it |
77 |
specifically. |
78 |
|
79 |
Unless of course you're referring to the fact that you can't normally |
80 |
combine 32-bit apps with 64-bit libs, or the reverse, a typical source of |
81 |
newbie confusion (and quite some emerge bugs when the build happens across |
82 |
the wrong bitness lib before it sees the correct one) on multilib setups. |
83 |
|
84 |
That, IMO, is one of the advantages of the separate 32-bit chroot concept, |
85 |
particularly with no-multilib. The main 64-bit system basically doesn't |
86 |
know it's there, it's just data to it, and the 32-bit chroot of course |
87 |
only knows about the parts of the 64-bit system that you've exposed to it |
88 |
thru bind-mounts, so there's very little chance of getting things mixed |
89 |
up, unless you deliberately mount a 64-bit libdir into the chroot or |
90 |
something, and as Gentooers should know by now, Gentoo does specifically |
91 |
allow you to (metaphorically) point a loaded gun at yourself and pull the |
92 |
trigger if you want, which is about what deliberately mounting a 64-bit |
93 |
libdir into the chroot would be doing. |
94 |
|
95 |
So... read my detailed response in the doomsday thread and the chroot |
96 |
guide, and that should give you a far better idea of whether what we're |
97 |
talking about is useful for you or not. |
98 |
|
99 |
Personally, I don't know. Honestly, it's definitely a lot of work, |
100 |
perhaps more than you're willing to put into it. |
101 |
|
102 |
You might be able to do what you want, and would arguably be better off, |
103 |
switching to a multilib profile and starting with a standard 64-bit |
104 |
stage-3 tarball again, to rebuild your Linux-side toolchain as multilib. |
105 |
That'll be some work now, but will definitely be less work maintaining |
106 |
than a 32-bit chroot. Unfortunately I don't know enough about the wine |
107 |
and MS platform cross-dev toolchain bit to evaluate what problems you |
108 |
might or might not have with that. I'm simply assuming it'll "just work" |
109 |
with a multilib profile, but that's a best-case assumption. |
110 |
|
111 |
OTOH, the 32-bit chroot concept, while definitely more work maintaining |
112 |
(it's roughly comparable work immediately to switching back to multilib, |
113 |
starting again from a standard multilib-compatible amd64 stage-3 tarball, |
114 |
but the 32-bit chroot will be more work maintaining over time as you'll be |
115 |
having to update stuff both on the main machine and in the chroot), *IS* a |
116 |
cleaner, more logically separate, solution. And, installing a 32-bit wine/ |
117 |
MS-platform cross-dev is much more likely a known quantity with any bug |
118 |
you might happen across much more common, than the dual bitness multilib |
119 |
concept. |
120 |
|
121 |
The thought occurs to me that it may hinge on 64-bit MS cross-dev status |
122 |
and whether you anticipate doing both 32-bit and 64-bit development, or |
123 |
only 32-bit. It's possible multilib would enable both, while you'd very |
124 |
likely have to have separate 32-bit and 64-bit cross-dev arrangements too, |
125 |
if your Linux host is separate 32-bit and 64-bit, as with the chroot |
126 |
solution. If you're not interested in the 64-bit MS side at all, that's |
127 |
not an issue. Likewise if your cross-dev solution doesn't include a |
128 |
64-bit MS side at all. But if you are and it does, then going the |
129 |
separate 32-bit chroot route on the Linux side probably necessitates a |
130 |
separate cross-dev for each as well, thus an even higher continuing |
131 |
maintenance burden choosing the separate chroot route. |
132 |
|
133 |
-- |
134 |
Duncan - List replies preferred. No HTML msgs. |
135 |
"Every nonfree program has a lord, a master -- |
136 |
and if you use the program, he is your master." Richard Stallman |