profiles: add example amd64 profile directories to support multilibpython

Signed-off-by: Gregory M. Tuner <gmt@be-evil.net>

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.