Re: [gentoo-amd64] Re: Wine with no-multilib on AMD64

[Mansour Al Akeel]

Thank you Duncan,
I checked this yesterday. In fact I was considering the idea of a
chroot last. And I didn't know there's a guide for it. The guide served
as a refrence in case I forgot something. 

In my case, having a separate 32 bit is a better option, since I have a
huge external hard disk, and use it mostely as a bootable server for
development and testing. In case I run low on resources on my laptop, I
just plug this usb drive in any PC and I have a fully running server to
deploy and test. After all, I don't that the chroot, is taking a lot of
room on my disk, and I'd rather not to use multilib for bad experience I
had with it, few years ago.

Things are working great for now. 


On Tue Mar 16,2010 01:56 am, Duncan wrote:
> 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
>
>