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 > >
