I have USE_PYTHON="2.6 2.7 3.2 2.7-pypy-1.9", and re-emerging gupnp-igd fails: checking for python extension module directory... ${exec_prefix}/lib64/pypy1.9/lib-python checking for headers required to compile python extensions... usage: /usr/bin/pypy-c1.9 [options] [-c cmd|-m mod|file.py|-] [arg...] options: -i inspect interactively after running script -O dummy optimization flag for compatibility with C Python -c cmd program passed in as CMD (terminates option list) -S do not 'import site' on initialization -u unbuffered binary stdout and stderr -h, --help show this help message and exit -m mod library module to be run as a script (terminates option list) -W arg warning control (arg is action:message:category:module:lineno) -E ignore environment variables (such as PYTHONPATH) --version print the PyPy version --info print translation information about this PyPy executable --jit OPTIONS advanced JIT options: try 'off' or 'help' not found configure: error: could not find Python headers !!! Please attach the following file when seeking support: !!! /var/tmp/portage/net-libs/gupnp-igd-0.2.2/work/gupnp-igd-0.2.2/config.log * ERROR: net-libs/gupnp-igd-0.2.2 failed (configure phase): * econf failed This seems to be due to code from m4/as-check-python-headers.m4: dnl Copy pasted from gst-python's acinclude.m4 file dnl a macro to check for ability to create python extensions dnl AM_CHECK_PYTHON_HEADERS([ACTION-IF-POSSIBLE], [ACTION-IF-NOT-POSSIBLE]) dnl function also defines PYTHON_INCLUDES AC_DEFUN([AM_CHECK_PYTHON_HEADERS], [AC_REQUIRE([AM_PATH_PYTHON]) AC_MSG_CHECKING(for headers required to compile python extensions) dnl deduce PYTHON_INCLUDES py_prefix=`$PYTHON -c "import sys; print sys.prefix"` py_exec_prefix=`$PYTHON -c "import sys; print sys.exec_prefix"` if $PYTHON-config --help 2>/dev/null; then PYTHON_INCLUDES=`$PYTHON-config --includes 2>/dev/null` else PYTHON_INCLUDES="-I${py_prefix}/include/python${PYTHON_VERSION}" if test "$py_prefix" != "$py_exec_prefix"; then PYTHON_INCLUDES="$PYTHON_INCLUDES -I${py_exec_prefix}/include/python${PYTHON_VERSION}" fi fi AC_SUBST(PYTHON_INCLUDES) dnl check if the headers exist: save_CPPFLAGS="$CPPFLAGS" CPPFLAGS="$CPPFLAGS $PYTHON_INCLUDES" AC_TRY_CPP([#include <Python.h>],dnl [AC_MSG_RESULT(found) $1],dnl [AC_MSG_RESULT(not found) $2]) CPPFLAGS="$save_CPPFLAGS" ]) As far as I can tell, the usage instructions come from a call like EPYTHON=pypy-c1.9 /usr/bin/python-config --help 2>/dev/null As that call returns zero, the PYTHON_INCLUDES variable will be determined using EPYTHON=pypy-c1.9 /usr/bin/python-config --includes 2>/dev/null which yields no output. Without the redirect, I see this error message instead: Unknown option: -- usage: /usr/bin/pypy-c1.9 [options] Try `/usr/bin/pypy-c1.9 -h` for more information. I'd say the main mistake here lies with the /usr/bin/python-config wrapper: #!/usr/bin/env bash # Gentoo python-config wrapper script [[ "${EPYTHON}" =~ (/|^python$) ]] && EPYTHON="python2.7" python_config="${EPYTHON/python/python-config-}" "${0%/*}/${python_config:-python-config-2.7}" "$@" The code which substitutes python-config for python assumes that EPYTHON contains the word "python", which is not the case for "pypy-c1.9". So for PyPy, executing python-config is the same as executing pypy itself, which isn't intended behaviour, is it? I guess the wrapper should check whether there really is a configure binary, different from the main executable, and return non-zero if there is none.
gupnp-igd-0.2.2-r1 (04 May 2013) 04 May 2013; Justin Lecher <jlec@gentoo.org> +gupnp-igd-0.2.2-r1.ebuild, +files/gupnp-igd-0.2.2-underlinking.patch, metadata.xml: Add fix for underlinking, fix obsolete macros in automake-1.13, #467888, fix python handling, #450392
