diff options
author | Gregory M. Tuner <gmt@be-evil.net> | 2014-01-07 05:34:07 -0800 |
---|---|---|
committer | Gregory M. Tuner <gmt@be-evil.net> | 2014-01-07 05:34:07 -0800 |
commit | dbbc61b519dc13eb8c8ace4ea89879dc7ab4b5bf (patch) | |
tree | e96e87c61fa8af4ee287e5460057d64f2f82f2c9 /README | |
parent | bring the python-multilib-r1 framework ebuilds into sync (diff) | |
download | gmt-dbbc61b519dc13eb8c8ace4ea89879dc7ab4b5bf.tar.gz gmt-dbbc61b519dc13eb8c8ace4ea89879dc7ab4b5bf.tar.bz2 gmt-dbbc61b519dc13eb8c8ace4ea89879dc7ab4b5bf.zip |
profiles: add example amd64 profile directories to support multilibpython
Signed-off-by: Gregory M. Tuner <gmt@be-evil.net>
Diffstat (limited to 'README')
-rw-r--r-- | README | 28 |
1 files changed, 14 insertions, 14 deletions
@@ -67,12 +67,16 @@ 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" # it's OK to have additional python's in there but 2.7 is required -PYTHON_TARGETS="python2_7" # likewise +USE_PYTHON="2.7" +PYTHON_TARGETS="python2_7" +PYTHON_MULTILIB_TARGETS_PYTHON2_7_X86="32 64" PYTHON_SINGLE_TARGET="python2_7" -ABI_X86="64 32" # It might work to put other stuff in there, but this is what I have +PYTHON_MULTILIB_SINGLE_TARGETS_PYTHON2_7_X86="32 64" +ABI_X86="64 32" # I put have x32 in here and elsewhere too but had to re-bootstrap glibc to make it work... gl! -- +then run 'eselect profile set "gmt:default/linux/amd64/13.0/developer/multilibpython"' + Now you will find that you are fucked. Congratulations! Portage will almost always complain that something is wrong no matter what @@ -85,14 +89,6 @@ with any luck, things will become less fucked as I continue my work. Notes: -Python 2.7 contains some very agressive, bad hacks. This will need to be completely -reworked before it's useful, but it's got just enough in there to make things -mostly work relative to what I have implemented so far. - -Python is the hardest part of the multi-abi puzzle, imo. I will get back to it soon, -hopefully with some less agressive hacks. For now, well, it does compile on my box -however YMMV. - If you are migrating from a normal multilib system to an ABI_X86-based system with this overlay, you're going to get caught in an circular-dependencies mess regarding gobject-introspection, dbus, glib, pango, and cairo. My only advice, for now, @@ -100,10 +96,14 @@ is to keep fiddling around and forcing things to build with "USE=-blah ebuild" u little gordian-dependency-knot unravels. Once that occurs, you'll still have an inconsistent package database but you'll be able to go much further with things. +If you are bootstrapping in to a triple-multilib environment with x32 as well, +you'll need to hack on glibc to bootstrap the multilib process. The trick +is to bootstrap with crossdev and wedge your crossdev compiler into the +glibc Makefiles after the ebuild crashes, and then restart... well it took a few +more tricks than that actually... but that will get you started. + You will probably have lots of collisions until you emerge the version of app-emulation/emul-linux-x86-baselibs from my overlay. Either force them or emerge app-emulation/emul-linux-x86-baselibs first. The way I did it was simply to remove app-emulation/emul-linux-x86-* entirely, and rely on '@preserved-rebuild' -to pick up the slack. Thus far, I don't think I've had to put any other -emul-linux-x86-* stuff back in except for baselibs, xlibs and opengl, the -latter two being empty placeholders. +to pick up the slack. |