WARNING: Don't use this overlay if you are not prepared to fix a broken gentoo installation! For now this overlay contains mostly my work-in-progress attempt to port lots and lots of ebuilds to support multilib-build. It's a work in progress and many things are expected to be broken. It also contains very, very experimental multilib python eclasses. These mostly work; however, I have decided to completely reimplement them as I've learned the hard way that I should have reversed the order of the USE_EXPAND arguments, and some non-PMS-compliant devices are utilized in the current multilib python codebase. The only thing I've had to do for no-multilib python ebuilds and eclasses (as of 12.14.31, I believe the only ebuild in the overlay with a multilib python dependency is =dev-lang/python-2.7.6-r1) is to add the occasional flag hack to support the nonstandard python header layout utilized by the multilib python installation. This was done because the only straightforward alternative was to wrap the pyconfig.h header in multilib python, using the built-in multilib-build header wrappers. I've opted not to do that because I was finding too many configure scripts that expected to parse out constants from pyconfig.h and project them into config.h constants. This would have been fine if they'd used cpp to do the parsing but a several scripts were instead employing far cruder "grep" type hacks. This would result in, at best, an error stating that pyconfig.h was invalid, or, at worst, erroneous values getting cached by configure which would compile fine but lead to runtime crashes later. The prospect that more of these could be lurking out there in unknown places was enough to scare me off from wrapping the python headers. Instead, I have ^-wrapped them. ^-wrapping is an overlay-only extension to the regular multilib-build wrapping which simply moves the conflicting headers to a per-ABI location but does not generate the wrapper. This gives us a nice clean all-or-nothing situation; if an ebuild depends on pyconfig.h, and no automated means of finding it is working (distutils-r1 and python-single-r1 eclasses have reasonably effective automated means of finding the appropriate headers), then it will crash stating that pyconfig.h cannot be found, and appropriate measures can be taken at the ebuild level. Meanwhile, any python ebuild that compiles will probably work fine. To use this overlay, you'll need to install it via layman. Since I implement extensive eclass overrides in here, you absolutely must hack up your /etc/portage/repos.conf approximately like so if the overlay is active: -- [DEFAULT] eclass-overrides = gmt main-repo = gentoo [gmt] priority=0 -- if you use this overlay without the eclass overrides, I can confidently assure you, some horrible shit is going to happen. If you're gonna use it, use the eclass override. If you have a local overlay that you want to take precedent over gmt, you should put that in your repos.conf, with a "priority" setting lower than that of "gmt". Use emerge --info --verbose to ensure that portage is ordering your overlays that way you want it to. Before you even start using this, you should remove it from your active layman overlays or disable it via repos.conf, and ensure the following prerequisites are met: you are on a multilib profile ACCEPT_KEYWORDS="~amd64" you have recently sync'ed portage your packages database is entirely consistent, in the sense that: # emerge -DupvN '@world' and # emerge --depclean and # emerge '@preserved-rebuild' and # revdep-rebuild all say there's nothing to do. Now that everything is running smoothly you're ready to break everything! :) add the gmt overlay back in, make the aformentioned changes to /etc/portage/repos.conf, and have the following in /etc/portage/make.conf (not precisely -- you'll want these in addition to whatever other stuff belongs there): -- USE_PYTHON="2.7" PYTHON_TARGETS="python2_7" ABI_X86="64 32" -- If you happen to have a triple-multilib toolchain you can use it, it should work fine (as fine as x32 gets at least, which on current ~amd64 means you'll need to mask any recent mesa libraries). then run 'eselect profile set "gmt:default/linux/amd64/13.0/developer/multilibpython"' One that's done, try emerging some stuff. If you jump straight into emerge -e '@world', you might get lucky but probably not. Portage will find circular dependencies or won't be willing to backtrack far enough to find a solution to the conflicts you've created and will give you an eyeful of garbage. It's probably better to start off getting @system re-emerged (without "--deep"), and then gradually resolving whatever madness ensues. If you start at the bottom of your dependency tree, and slowly work your way up, will be able to get most stuff working again. As of this writing, I have a perfectly consistent package database as defined above using this overlay. That may not be possible for you, without adjusting some use flags. I've done my best to try various combinations of flags, but it would be a practical impossibility for me to try the bazillions of permutations possible, and certain flags (i.e.: ldap), I'm just haven't had the chance to dink around with yet. A final note: your MULTILIB_ABIS variable must be a superset of your ABI_X86 variable; otherwise you are writing a check that your toolchain can't cash! The mapping between them is: MULTILIB_ABIS ABI_X86 ============= ======= amd64 64 x86 32 x32 x32 Another thing to be aware of is that a very significant number of bugs exist in the upstream code pertaining to crossdev. Many of these have been worked around in this overlay, often requiring nontrivial efforts to do so. But in general, if you have a crossdev toolchain whose ARCH matches the pseudo-ARCH corresponding to your multilib targets, expect things to be less stable. The most likely scenario of this nature would be that you are on an ~amd64 profile and have an i686-pc-linux-gnu crossdev toolchain. It helps somewhat to tell binutils-config to generate "fake" targets for x86 by passing it the --x86 argument; however, this is a half-measure. Autotools will pick the crossdev toolchain elements up automatically almost every time. For things like "ar" this is not a problem and you will get away with even really drastic things like accidentally using the crossdev i686-pc-linux-gnu-gcc -- but know that this is wrong and will lead to problems very frequently. Specific countermeasures are taken in this overlay to prevent the crossdev pkg-config wrappers from being chosen by autotools, however, most build systems seem to (almost desperately) want to use those, and this will lead to utter disaster very frequently when it happens. Your best bet is simply to unmerge your i686-pc-linux-gnu crossdev target once you are confident that your x86_64-pc-linux-gnu toolchain is consistently doing the right thing with -m32. After all, technically speaking, at that point, you really don't need it anymore. Long story short: keep your crossdev stuff in a prefix or a chroot or something, unless you like fixing problems!