From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1NrYIf-0003d8-6x for garchives@archives.gentoo.org; Tue, 16 Mar 2010 15:03:20 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A6D62E0C33 for ; Tue, 16 Mar 2010 15:03:14 +0000 (UTC) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by pigeon.gentoo.org (Postfix) with ESMTP id 7082CE086A for ; Tue, 16 Mar 2010 14:51:59 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id e21so1428267fga.10 for ; Tue, 16 Mar 2010 07:51:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=66Vt2FiqoAdJC92l5JAMPETBe1DbziE+RaKVc+5QnZI=; b=U41/cK5LzTMwyChljM28Whz75nBvgvTvwhaawwe9wymvY7dK1UEoZNGOwCvmvh5/4h 6KPgINSQ7kysSIROOrvyJjN9dWpuqupOI8GsQf6ZBDmwwKqV5saFPoTY1B0GpZlLntMB neyE+yIihnC9AKqsGBxgzrQjYBoTr2boQh1c4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=aigZCawGaCKKFdjehVibIo8DG+GX35Hg+NGG76Wa82FmKAZOGAdivOUtvbK4vfn1Jv FWUz/T+nJfMGbPk9e5yGVpdq6nNhr36wPYSmW3ps7QcBm5FiDQRzTyry3xOuuSGH6RtN Ta0ySTCBKna6fLqV+lc3GqA5py9ElbX0FhuM0= Received: by 10.87.45.20 with SMTP id x20mr10338676fgj.63.1268751118368; Tue, 16 Mar 2010 07:51:58 -0700 (PDT) Received: from mars.lan (CPE0014bf895399-CM0014f8c19014.cpe.net.cable.rogers.com [99.246.237.4]) by mx.google.com with ESMTPS id 3sm322299fge.20.2010.03.16.07.51.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Mar 2010 07:51:56 -0700 (PDT) Date: Tue, 16 Mar 2010 11:51:53 -0300 From: Mansour Al Akeel To: gentoo-amd64@lists.gentoo.org Subject: Re: [gentoo-amd64] Re: Wine with no-multilib on AMD64 Message-ID: <20100316145151.GB4691@mars.lan> References: <20100313141534.GA7803@mars.lan> <201003131629.06701.volkerarmin@googlemail.com> <20100315180447.GB8561@mars.lan> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@lists.gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Archives-Salt: 056079ab-c243-4b4d-a26e-77a7e9bda887 X-Archives-Hash: 74a43caf8e2a254638ed2027bcd02d8c 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 > >