Emerging dev-lang/python-2.5.1-r2 fails with: Compiling /Users/bunge/gentoo/var/tmp/portage/dev-lang/python-2.5.1-r2/image//Users/bunge/gentoo/usr/lib/python2.5/xmlrpclib.py ... Compiling /Users/bunge/gentoo/var/tmp/portage/dev-lang/python-2.5.1-r2/image//Users/bunge/gentoo/usr/lib/python2.5/zipfile.py ... make: *** [libinstall] Error 1 * * ERROR: dev-lang/python-2.5.1-r2 failed. * Call stack: * ebuild.sh, line 1592: Called dyn_install * ebuild.sh, line 1027: Called qa_call 'src_install' * ebuild.sh, line 44: Called src_install * python-2.5.1-r2.ebuild, line 197: Called die * * (no error message) * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/Users/bunge/gentoo/var/tmp/portage/dev-lang/python-2.5.1-r2/temp/build.log'. * Searching in the build.log reveals the following: Compiling /Users/bunge/gentoo/var/tmp/portage/dev-lang/python-2.5.1-r2/image//Users/bunge/gentoo/usr/lib/python2.5/test/test_module.py ... Compiling /Users/bunge/gentoo/var/tmp/portage/dev-lang/python-2.5.1-r2/image//Users/bunge/gentoo/usr/lib/python2.5/test/test_multibytecodec.py ... Sorry: UnicodeError: ("\\N escapes not supported (can't load unicodedata module)",) Compiling /Users/bunge/gentoo/var/tmp/portage/dev-lang/python-2.5.1-r2/image//Users/bunge/gentoo/usr/lib/python2.5/test/test_multibytecodec_support.py ... Which can be traced to be the reason of the failed merge. Reproducible: Always
The problem can be circumvented by uncommenting line 180 in Modules/Setup.dist ("unicodedata unicodedata.c") as described here: http://www.techlists.org/archives/programming/pythonlist/2007-06/msg00473.shtml I've modified the ebuild accordingly and python merges fine this way. However, this seems like more of a hack than an actual solution. See the discussion here as well: http://www.mail-archive.com/python-bugs-list@python.org/msg09596.html I need to catch some sleep now... Thanks in advance for the help!
Python 2.5 should be masked for this screw-up. I don't know why, but compiling python is even worse than using the language itself. That unicodedata module *should* load before it can be unmasked. We had a similar issue for 2.4 (why not, python has a good reputation to keep up with being broken) but I couldn't seem to fix it that way this time.
Okay... I've make some progress on this. I've compiled python from scratch and as long as the dylib patch is not applied (and *.so files are created... *ahem*) the python build binary loads them fine and `make altinstall` completes without problems. So it seems that the python binary fails to search for the dylib files correctly. I'm going to look into this later how I can apply the dylib patch and then still make python recognize the libraries. Have to go elsewhere now, but I thought I would post this so someone who is familiar with the ebuild might be able to look into it already.
ok, thanks. The main tree bumped the python version, so I'm going to sync it first.
Couldn't sleep and I can't put down a problem as long as I haven't fixed it... Found this in configure.in: "Use dynload_next.c only on 10.2 and below, which don't have native dlopen()"... aha! Patched dynload_shlib.c accordingly and Python-2.5.1 merges fine!! I also found out why python used .so files and not .dyload files, although I find it a rather superficial excuse: http://bugs.python.org/msg41724
Created attachment 129102 [details, diff] Dylib patch for dev-lang/python-2.5.1 Here's my suggestion for a patch (this replaces python-2.4.4-darwin-dylib.patch). I wrote it in a way that it can be submitted upstream as well. I'm considering posting a new bug on python.org despite the aforementioned discussion.
If Jack (a collegue of mine) thinks that .so is right on a Mac, then you have almost no chance. He's *the* Mac man, and clearly lost his mind on this point.
That original bug reporter (ronaldsoussoren) is also known to us, he works on Mac stuff for someone who used to be a collegue of Jack. They turn down the patch also because backwards compatibility gets broken once you apply it. In Gentoo we don't have this, as we build up everything. Compiling now. Thanks a lot for diving into it... (now I have to get the patch to get to apply here)
congratulations Philipp! You made it really work. Portage even appears to still work, and python-updater does it's job at the moment. I'll be committing a modified version of your patch soon!
Excellent! Thank you! I'll save me the effort of opening a bug on python.org in that case. :-)
