Hey :) i just upgraded to latest eselect and eselect-python in course of updating all my production prefixes (interix 3.5/5.2/6.0/6.1). After upgrading, pygobject cannot be built, since configure cannot find Python.h. my own search brought up this file: /opt/gentoo/usr/include/python2.6/Python.h however, how would the compiler supposed to find this file? shouldn't there be symlinks to python includes in /usr/include? am i missing something? i'll attach pygobjects config.log FYI.
Created attachment 202114 [details] pygobject config.log
Looks like a Prefix specific problem of the python.eselect module to me. Reassigning.
it used to work, didn't it? Probably something changed between the current and the previous version in the python.eselect file then
err... i dont' know. a quick look over eselect-python did not show anything related to includes... (!?) 5 DESCRIPTION="Manage the /usr/bin/python and python.1 man symlinks." 6 MAINTAINER="python@gentoo.org" 7 SVN_DATE='$Date: 2009-08-04 20:46:11 +0000 (Tue, 04 Aug 2009) $' 8 VERSION=$(svn_date_to_version "${SVN_DATE}" )
I'll have a look during this (boring conference) talk
hm. looking at oldish snapshots of mine, i realized that python did install it's header files in usr/include/python2.6 before - so this is not new. how is a correct configure check for python.h supposed to find it? is there some python-config or so, that has to be asked for additional include paths? maybe the configure check for python.h in pygobject is broken, not eselect-python?
well, you should have a usr/include/Python.h IMO, which is managed by eselect-python
ok, cool, I don't have it here either
uhm - digging a little deeper: pygobject seems to do it correctly, but python-config cores... ugh: 94 if test -x "$PYTHON-config"; then 95 PYTHON_INCLUDES=`$PYTHON-config --includes 2>/dev/null` 96 else 97 PYTHON_INCLUDES="-I${py_prefix}/include/python${PYTHON_VERSION}" 98 if test "$py_prefix" != "$py_exec_prefix"; then 99 PYTHON_INCLUDES="$PYTHON_INCLUDES -I${py_exec_prefix}/include/python${PYT HON_VERSION}" 100 fi 101 fi 102 + test -x /opt/gentoo/usr/bin/python-config 103 + /opt/gentoo/usr/bin/python-config --includes 104 + 2> /dev/null 105 Memory fault (core dumped) 106 + PYTHON_INCLUDES= 107 still searching... :)
(In reply to comment #7) > well, you should have a usr/include/Python.h IMO, which is managed by > eselect-python that was what i assumed initially, and why i started this bug/posted to the ml...
wow - python-config when run manages to make a vim in the background crash (!!!!) something _really_ bad is happening here (on all interix versions). it did work before, so - some recent change must have destroyed it ;)
ah, python dumping core makes it a regular (normal) python problem on normal Gentoo linux, usr/include doesn't contain Python.h either, so that's a wrong assumption of mine
hahahaha... i have found the problem: the shebang of python-config: #!/bin/bash but i have no bash. and this f****** interix just segfaults on that. grmpf. every once in a while i stumble over this sh**. never mind, i'll fix it :)
what do you think about something simliar to the binchecks in install_qa_check in ebuild.sh to check the shebang of scripts? it's really mean that interix just crashes on a wrong shebang, espacially because that can cause really hard to find problems.
fixed in eselect-python-20090814-r00.1
(In reply to comment #14) > what do you think about something simliar to the binchecks in install_qa_check > in ebuild.sh to check the shebang of scripts? > > it's really mean that interix just crashes on a wrong shebang, espacially > because that can cause really hard to find problems. I think that's a really good idea, I'll look into it