From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.62) (envelope-from ) id 1GveAQ-00044u-Th for garchives@archives.gentoo.org; Sat, 16 Dec 2006 18:21:51 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.8/8.13.8) with SMTP id kBGIHvYu001814; Sat, 16 Dec 2006 18:17:57 GMT Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by robin.gentoo.org (8.13.8/8.13.8) with ESMTP id kBGIHuLv028497 for ; Sat, 16 Dec 2006 18:17:56 GMT Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gve6d-0000SA-AK for gentoo-amd64@lists.gentoo.org; Sat, 16 Dec 2006 19:17:55 +0100 Received: from ip68-231-13-122.ph.ph.cox.net ([68.231.13.122]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 Dec 2006 19:17:55 +0100 Received: from 1i5t5.duncan by ip68-231-13-122.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 Dec 2006 19:17:55 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: Emerging package as both 64 and 32 bit Date: Sat, 16 Dec 2006 18:17:43 +0000 (UTC) Message-ID: References: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-13-122.ph.ph.cox.net User-Agent: pan 0.120 (Plate of Shrimp) Sender: news X-Archives-Salt: 9c877dc3-31c1-43de-9b67-e8e5f53f5636 X-Archives-Hash: d60b0d0003a38b3bf498dab5834bed96 "Boky Boky" posted e8666cf90612160745k19aa5622ueb3c7e84295285bc@mail.gmail.com, excerpted below, on Sat, 16 Dec 2006 16:45:24 +0100: > Anyways, is it possible to emerge the same package in parallel? As > 32-bit and 64-bit version? > > Something in the lines of: > ABI="amd64,x86" emerge libxml2 > > or: > emerge libxml2 > ABI="x86" emerge > --some-option-to-ignore-already-installed-package-and-not-remove-it > libxml2 > Namely, I am trying to compile openoffice (using ABI="x86") and some GTK > themes. > > openoffice depends one some packages (libxml2, libz, ...) that need > therefore need to exist in 32-bit and I'd like to have firefox (...and > other 32bit apps) themed not just with themes that come with emul-* > packages. You can do what you are trying to do, but it's more work than it might first appear. The problem is that portage isn't multi-ABI aware. As far as it is concerned, if a dependency is merged for one or the other, it's merged, period. If you merge a second ABI, it will erase what it knows of the first. There are as a result very specific cautions against trying to merge both ABIs using the same portage database. It can and likely WILL screw up your system BIG TIME, because portage won't have the foggiest which end is up or down in terms of what's installed for what bitness, once you start to mix them. As I said, however, there IS a way to do it -- actually two, but in general only one solution of the two will fit your needs. The first way works best if you only have a few second-ABI things you wish to install, using the emul- or -bin stuff for the rest. Basically, this method consists of installing everything "extra" that you need for the second ABI manually -- without using portage directly. You get the tarball, unpack it, verify that you have the dependencies it needs in the desired ABI (you either have them as -emul/-bin or you already did this same process with them), apply any desired patches, configure, build, and install, all manually. You can look at the ebuild script to see if it does anything special and do the same things manually if you want the same thing that the ebuild /would/ give you, but you don't do it with portage so it's not in the portage database and therefore can't screw it up. The CFLAGS for 32-bit would include -m32, and when you run configure, you'd supply the command line options to point it at the 32-bit libraries and etc. The second way works best if you have more than a handful of things to build, because it's a bigger hassle to setup initially, but all the usual stuff is automated after that. Basically, you setup a 32-bit chroot that has most of a 32-bit system -- leaving out stuff like the kernel and system services of course because you have them in 64-bit mode already, but starting from a regular x86 stage-whatever and building all the supporting libraries and other dependencies as 32-bit, using a second chrooted 32-bit only version of portage, with its own database (you can point it at the same portage tree, of course), so it's not going to overwrite your main system 64-bit database. There's a HOWTO for doing the 32-bit chroot. I'll link it below. This is covered there but sketching it out briefly... You can make use of the mount --bind option to remount filesystems or portions of filesystems (directories) so they are seen in both the original location and in the chroot. It's often convenient to mount /home and /tmp, and your portage tree, this way, for instance, while keeping stuff like /usr separate, so merges in the chroot have no chance of overwriting your 64-bit stuff outside the chroot. Except for maintaining the chroot, for which you'll always want to go into the chroot to avoid the possibility of overwriting your main system, it's possible to add the 32-bit paths and library paths (for ld) to your main paths and run both 32-bit and 64-bit stuff from your main system outside the chroot. If you have the same executables merged in both 32-bit and 64-bit, the order of your path will naturally determine which one is called if you don't specify the one you want by specifying the path with the command. Of course, with the 32-bit chroot, you are building most of a 32-bit system anyway, so it's not hard (simpler but more building to do, so take your pick) to go all the way if desired, building the 32-bit kernel and services, after which you can add a 32-bit boot option to your grub/lilo boot menu and dual boot, if desired. =8^) Official Gentoo/amd64 32-bit chroot HOWTO: http://www.gentoo.org/proj/en/base/amd64/howtos/chroot.xml For a variation on the 32-bit chroot that involves creating it, then using it to build your own 32-bit emul- packages that you can merge on your 64-bit system without screwing up its database, check here. (This is NOT official Gentoo, just something a Gentoo/amd64 user put up. I'm not sure if it's fully upto date, but the idea will remain the same even if you have to tweak the specifics a bit.) It's worth a read, anyway, just to see how it can be done, whether you choose to do it yourself or not. Unofficial (User's) Gentoo/amd64 Creating your own 32-bit emul packages HOWTO: http://www.andyjeffries.co.uk/32bit-ebuild-amd64.html -- 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 -- gentoo-amd64@gentoo.org mailing list