Re: [Xen-devel] [PATCH v2] autoconf: check for Python.h header and -lpython* lib

[Roger Pau Monnà <roger.pau@xxxxxxxxxxxxx>]

2012/3/20 Jan Beulich <JBeulich@xxxxxxxx>:
>>>> On 20.03.12 at 14:06, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>>>>> On 12.03.12 at 14:35, Roger Pau MonnÃ<roger.pau@xxxxxxxxxxxxx> wrote:
>>> 2012/3/12 Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>:
>>>> Roger Pau Monne writes ("[PATCH v2] autoconf: check for Python.h header and
>>> -lpython* lib"):
>>>>> autoconf: check for Python.h header and -lpython* lib
>>>>
>>>> Right, this is better.
>>>>
>>>>> +ac_previous_cppflags=$CPPFLAGS
>>>> ...
>>>>> +AC_CHECK_HEADER([Python.h], [],
>>>>> + Â Â[AC_MSG_ERROR([Unable to find Python development headers])],)
>>>>> +AC_CHECK_LIB($python_lib, PyArg_ParseTuple, [],
>>>>> + Â Â[AC_MSG_ERROR([Unable to find a suitable python development 
>>>>> library])])
>>>>> +CPPFLAGS=$ac_previous_cppflags
>>>>> +LDLFAGS=$ac_previous_ldflags
>>>>
>>>> But AFAICT we go to all this effort to find the right python flags and
>>>> then we throw them away. ÂThis is a bit odd. ÂShouldn't we be passing
>>>> this in some PYTHON_FOOFLAGS variables for the benefit of tools/python ?
>>>
>>> This would only be needed to compile Python C modules, but since
>>> python uses it's own standart build script (tools/python/setup.py) and
>>> we already pass to the setup.py script the desired python version to
>>> use, it already fetches the necessary includes/libs using it's own
>>> mechanisms.
>>
>> I'm sorry to say that, but this change is pretty incompatible: Not only
>> does Python not provide any python-config prior to 2.5.x, but
>> additionally was Ian's point above very valid: Stripping all the other
>> -l options causes a configure failure for me:
>>
>> configure:6176: checking for PyArg_ParseTuple in -lpython2.4
>> configure:6201: gcc -o conftest Â-g -O2 Â -g -O2 Â-I/usr/include/python2.4
>> -I/usr/include/python2.4
>> -L/usr/lib/python2.4/config conftest.c -lpython2.4 Â >&5
>> /usr/lib/python2.4/config/libpython2.4.a(posixmodule.o): In function
>> `posix_tmpnam':
>> (.text+0x81e): warning: the use of `tmpnam_r' is dangerous, better use
>> `mkstemp'
>> /usr/lib/python2.4/config/libpython2.4.a(posixmodule.o): In function
>> `posix_tempnam':
>> (.text+0x90c): warning: the use of `tempnam' is dangerous, better use
>> `mkstemp'
>> /usr/lib/python2.4/config/libpython2.4.a(complexobject.o): In function
>> `complex_abs':
>> (.text+0x54d): undefined reference to `hypot'
>> /usr/lib/python2.4/config/libpython2.4.a(complexobject.o): In function
>> `_Py_c_pow':
>> (.text+0x2418): undefined reference to `hypot'
>> /usr/lib/python2.4/config/libpython2.4.a(complexobject.o): In function
>> `_Py_c_pow':
>> (.text+0x242a): undefined reference to `pow'
>> /usr/lib/python2.4/config/libpython2.4.a(complexobject.o): In function
>> `_Py_c_pow':
>> (.text+0x243f): undefined reference to `atan2'
>> /usr/lib/python2.4/config/libpython2.4.a(complexobject.o): In function
>> `_Py_c_pow':
>> (.text+0x2470): undefined reference to `cos'
>> /usr/lib/python2.4/config/libpython2.4.a(complexobject.o): In function
>> `_Py_c_pow':
>> (.text+0x2483): undefined reference to `sin'
>> /usr/lib/python2.4/config/libpython2.4.a(complexobject.o): In function
>> `_Py_c_pow':
>> (.text+0x24f6): undefined reference to `exp'
>> /usr/lib/python2.4/config/libpython2.4.a(complexobject.o): In function
>> `_Py_c_pow':
>> (.text+0x2507): undefined reference to `log'
>> /usr/lib/python2.4/config/libpython2.4.a(floatobject.o): In function
>> `float_rem':
>> (.text+0x17c8): undefined reference to `fmod'
>> /usr/lib/python2.4/config/libpython2.4.a(floatobject.o): In function
>> `float_divmod':
>> (.text+0x25a8): undefined reference to `fmod'
>> /usr/lib/python2.4/config/libpython2.4.a(floatobject.o): In function
>> `float_pow':
>> (.text+0x296f): undefined reference to `pow'
>> /usr/lib/python2.4/config/libpython2.4.a(floatobject.o): In function
>> `float_pow':
>> (.text+0x2a03): undefined reference to `fmod'
>> /usr/lib/python2.4/config/libpython2.4.a(dynload_shlib.o): In function
>> `_PyImport_GetDynLoadFunc':
>> (.text+0x12e): undefined reference to `dlsym'
>> /usr/lib/python2.4/config/libpython2.4.a(dynload_shlib.o): In function
>> `_PyImport_GetDynLoadFunc':
>> (.text+0x195): undefined reference to `dlopen'
>> /usr/lib/python2.4/config/libpython2.4.a(dynload_shlib.o): In function
>> `_PyImport_GetDynLoadFunc':
>> (.text+0x1c3): undefined reference to `dlsym'
>> /usr/lib/python2.4/config/libpython2.4.a(dynload_shlib.o): In function
>> `_PyImport_GetDynLoadFunc':
>> (.text+0x232): undefined reference to `dlerror'
>> /usr/lib/python2.4/config/libpython2.4.a(thread.o): In function
>> `PyThread_release_lock':
>> (.text+0x49): undefined reference to `sem_post'
>> /usr/lib/python2.4/config/libpython2.4.a(thread.o): In function
>> `PyThread_acquire_lock':
>> (.text+0xc7): undefined reference to `sem_wait'
>> /usr/lib/python2.4/config/libpython2.4.a(thread.o): In function
>> `PyThread_acquire_lock':
>> (.text+0xe2): undefined reference to `sem_trywait'
>> /usr/lib/python2.4/config/libpython2.4.a(thread.o): In function
>> `PyThread_free_lock':
>> (.text+0x1f2): undefined reference to `sem_destroy'
>> /usr/lib/python2.4/config/libpython2.4.a(thread.o): In function
>> `PyThread_allocate_lock':
>> (.text+0x267): undefined reference to `sem_init'
>> /usr/lib/python2.4/config/libpython2.4.a(thread.o): In function
>> `PyThread_start_new_thread':
>> (.text+0x568): undefined reference to `pthread_create'
>> /usr/lib/python2.4/config/libpython2.4.a(thread.o): In function
>> `PyThread_start_new_thread':
>> (.text+0x586): undefined reference to `pthread_detach'
>> /usr/lib/python2.4/config/libpython2.4.a(posixmodule.o): In function
>> `posix_forkpty':
>> (.text+0x3189): undefined reference to `forkpty'
>> /usr/lib/python2.4/config/libpython2.4.a(posixmodule.o): In function
>> `posix_openpty':
>> (.text+0x3218): undefined reference to `openpty'
>> collect2: ld returned 1 exit status
>>
>> As you can see, all unresolved symbols revolve around symbols from
>> those other libraries - the symbol looked for (PyArg_ParseTuple) is not
>> among them.
>
> A sketched out partial fix for this might be

I've already posted something arround this lines a few days ago:

http://lists.xen.org/archives/html/xen-devel/2012-03/msg01350.html

What I didn't know was that python-config was only available starting
from 2.5, which is a real pain in the ass, I will probably have to
drop the python-config stuff and move to distutils to perform this
checks. Sorry for the trouble this is causing you (Jan), it's
impossible for me to test on all systems/python versions that are
*supported*, and I tend to run this on pretty new systems.

>
> --- a/tools/m4/python_devel.m4
> +++ b/tools/m4/python_devel.m4
> @@ -2,17 +2,18 @@ AC_DEFUN([AX_CHECK_PYTHON_DEVEL], [
> Âac_previous_cppflags=$CPPFLAGS
> ÂCPPFLAGS="$CFLAGS `$PYTHON-config --includes`"
> Âac_previous_ldflags=$LDFLAGS
> +python_other_libs=
> Âfor flag in `$PYTHON-config --ldflags`
> Âdo
> Â Â case $flag in
> Â Â -L*)
> - Â Â Â ÂLDFLAGS="$LDLFAGS $flag"
> + Â Â Â ÂLDFLAGS="$LDFLAGS $flag"
> Â Â Â Â ;;
> Â Â -lpython*)
> Â Â Â Â python_lib=`echo $flag | sed 's/^-l//'`
> Â Â Â Â ;;
> Â Â -l*)
> - Â Â Â Â# Ignore other libraries, we are only interested in testing 
> python-dev
> + Â Â Â Âpython_other_libs="$python_other_libs $flag"
> Â Â Â Â ;;
> Â Â *)
> Â Â Â Â AC_MSG_WARN([Strange ldflag found in $PYTHON-config output: $flag])
> @@ -22,7 +23,8 @@ done
> ÂAC_CHECK_HEADER([Python.h], [],
> Â Â [AC_MSG_ERROR([Unable to find Python development headers])],)
> ÂAC_CHECK_LIB($python_lib, PyArg_ParseTuple, [],
> - Â Â[AC_MSG_ERROR([Unable to find a suitable python development library])])
> + Â Â[AC_MSG_ERROR([Unable to find a suitable python development library])],
> + Â Â[$python_other_libs])
> ÂCPPFLAGS=$ac_previous_cppflags
> ÂLDLFAGS=$ac_previous_ldflags
> Â])
>
> I didn't really re-generate tools/configure though (not sure what
> autoconf version would be required, and surely this wouldn't match
> the ones I have around), so can't claim this is syntactically correct.
> For my purposes I instead patched tools/configure manually.
>
> Partial because it doesn't address the lack of python-config on pre-2.5
> Python (we require >= 2.3).
>
> I also wonder whether the -lpython* case shouldn't be cumulative in
> case there's more than one matching option.

I don't think python-config will output more than one -lpython*, I
have systems with more than one python version, and I have
python(version)-config for each one of them, but plain python-config
just outputs a single version to link to.

> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel