[gentoo-amd64] Re: Emerging package as both 64 and 32 bit

[Duncan]

"Boky Boky" <verynotbad@×××××.com> posted
e8666cf90612160745k19aa5622ueb3c7e84295285bc@××××××××××.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@g.o mailing list