aboutsummaryrefslogtreecommitdiff
path: root/README
diff options
context:
space:
mode:
authorGregory M. Tuner <gmt@be-evil.net>2014-01-07 05:34:07 -0800
committerGregory M. Tuner <gmt@be-evil.net>2014-01-07 05:34:07 -0800
commitdbbc61b519dc13eb8c8ace4ea89879dc7ab4b5bf (patch)
treee96e87c61fa8af4ee287e5460057d64f2f82f2c9 /README
parentbring the python-multilib-r1 framework ebuilds into sync (diff)
downloadgmt-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--README28
1 files changed, 14 insertions, 14 deletions
diff --git a/README b/README
index 31ca9af..e50cf86 100644
--- a/README
+++ b/README
@@ -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.