Mansour Al Akeel posted on Mon, 15 Mar 2010 15:04:49 -0300 as excerpted:
> Hello Duncan:
> Pleae read my comments.
>
> On Sat Mar 13,2010 10:20 pm, Duncan wrote:
>> Volker Armin Hemmann posted on Sat, 13 Mar 2010 16:29:06 +0100 as
>> excerpted:
>>
>> > On Samstag 13 M??rz 2010, Mansour Al Akeel wrote:
>> >> Hello all,
>> >>
>> >> I have been looking into installing wine and a cross dev tool chain.
>> >> I didn't get much luck, since I have amd64 and I use no-multilib. I
>> >> found this http://bugs.gentoo.org/269439 and I am wondering if any
>> >> one can provide an advice. Is it be possible to run wine on amd64
>> >> with no-multilib ?
>> >
>> > you won't be able to run any 32bit windows app. Which makes wine
>> > pretty useless.
>>
>> FWIW, I have no-multilib, but with the 32-bit compatibility turned on
>> in the kernel, I'm able to do the 32-bit chroot thing as in the
>> gentoo/amd64 documentation.
>>
>> In my case, I'm doing a full 32-bit chroot image, which then gets
>> transferred to my AA1 netbook. (The big machine has far more memory
>> and power to do the compiles, so it makes more sense to do that and not
>> even have the gentoo tree on the netbook, just transfer over the
>> prebuilt, preconfigured image, and rsync it again after every update.
>> I've never booted the 32-bit image on the big machine, tho, and indeed,
>> couldn't, as the kernel drivers, etc, are all built-in and configured
>> for the netbook.)
>
> Are you saying that you have another 32bit gentoo image, and you mount
> it somewhere and chroot to it? If so, what does the memory has to do
> with this ? Can you please elaborate on this ? The space is not a
> concern to me, but I'd rather not mix 32 and 64 libs.
Yes. I have a 32-bit chroot image that gets mounted and chrooted into
(using linux32 chroot ...) as per the gentoo/amd64 32-bit chroot guide.
That works just fine with no-multilib, and indeed, multilib would
duplicate functionality to some degree. Just make sure your kernel has
32-bit "emulation" turned on (tho it's not really emulation, in the same
way that wine is not an emulator, amd64/x86_64 is true dual-bitness
hardware).
I posted the link to the guide in the doomsday thread pretty much
concurrently to the discussion here, but for convenience, here's the link:
http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=2 That explains the process and covers the step-by-step quite nicely. I
discuss it in more depth in the doomsday thread, so I'd suggest you read
it if you're seriously interested in this. Meanwhile...
As mentioned, I use the 32-bit chroot for a somewhat different purpose,
building a separate 32-bit image to run on my 32-bit-only netbook. As
such, I have a fully configured and bootable build-out of the 32-bit as if
it were an entirely separate machine, even if I never boot to it on this
machine, because it is intended to run on a separate machine. However,
while that's a reasonably trivial extension from the 32-bit chroot guide,
it's not why it was written, nor what it directly addresses. But as you
specify, it's definitely entirely separate, no mixed 32/64-bit as multilib
does, or it'd be unsuitable for the 32-bit-only machine usage to which I
put it. So rest assured on that point. The only mixing between the two
systems are mount-binds setup to expose stuff like a common tempdir
between the two systems (and of course that you happen to be running on a
64-bit host kernel in the first place), and it's relatively trivial to
simply not mount-bind what you specifically don't need. If you're
familiar with chroots, mount-binds for access within the chroot are pretty
standard stuff, and it /is/ a chroot, so it's as entirely separate as a
chroot normally would be.
As to your specific question "what does the memory have to do with this?",
I don't quite understand the question, so pardon my not answering it
specifically.
Unless of course you're referring to the fact that you can't normally
combine 32-bit apps with 64-bit libs, or the reverse, a typical source of
newbie confusion (and quite some emerge bugs when the build happens across
the wrong bitness lib before it sees the correct one) on multilib setups.
That, IMO, is one of the advantages of the separate 32-bit chroot concept,
particularly with no-multilib. The main 64-bit system basically doesn't
know it's there, it's just data to it, and the 32-bit chroot of course
only knows about the parts of the 64-bit system that you've exposed to it
thru bind-mounts, so there's very little chance of getting things mixed
up, unless you deliberately mount a 64-bit libdir into the chroot or
something, and as Gentooers should know by now, Gentoo does specifically
allow you to (metaphorically) point a loaded gun at yourself and pull the
trigger if you want, which is about what deliberately mounting a 64-bit
libdir into the chroot would be doing.
So... read my detailed response in the doomsday thread and the chroot
guide, and that should give you a far better idea of whether what we're
talking about is useful for you or not.
Personally, I don't know. Honestly, it's definitely a lot of work,
perhaps more than you're willing to put into it.
You might be able to do what you want, and would arguably be better off,
switching to a multilib profile and starting with a standard 64-bit
stage-3 tarball again, to rebuild your Linux-side toolchain as multilib.
That'll be some work now, but will definitely be less work maintaining
than a 32-bit chroot. Unfortunately I don't know enough about the wine
and MS platform cross-dev toolchain bit to evaluate what problems you
might or might not have with that. I'm simply assuming it'll "just work"
with a multilib profile, but that's a best-case assumption.
OTOH, the 32-bit chroot concept, while definitely more work maintaining
(it's roughly comparable work immediately to switching back to multilib,
starting again from a standard multilib-compatible amd64 stage-3 tarball,
but the 32-bit chroot will be more work maintaining over time as you'll be
having to update stuff both on the main machine and in the chroot), *IS* a
cleaner, more logically separate, solution. And, installing a 32-bit wine/
MS-platform cross-dev is much more likely a known quantity with any bug
you might happen across much more common, than the dual bitness multilib
concept.
The thought occurs to me that it may hinge on 64-bit MS cross-dev status
and whether you anticipate doing both 32-bit and 64-bit development, or
only 32-bit. It's possible multilib would enable both, while you'd very
likely have to have separate 32-bit and 64-bit cross-dev arrangements too,
if your Linux host is separate 32-bit and 64-bit, as with the chroot
solution. If you're not interested in the 64-bit MS side at all, that's
not an issue. Likewise if your cross-dev solution doesn't include a
64-bit MS side at all. But if you are and it does, then going the
separate 32-bit chroot route on the Linux side probably necessitates a
separate cross-dev for each as well, thus an even higher continuing
maintenance burden choosing the separate chroot route.
--
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