Re: [Boost-testing] [Martin Wille] Python tests

From: David Abrahams (dave_at_[hidden])
Date: 2006-10-02 05:37:54

Martin Wille <mw8329_at_[hidden]> writes:

> David Abrahams wrote:
>> Martin Wille writes:
>> 
>>> David Abrahams wrote:
>
>>>> Hi Martin,
>>>>
>>>> http://tinyurl.com/hznkp seems to indicate that recent changes I made
>>>> to tools/build/v2/tools/python.jam may be interfering with your
>>>> configuration.  Could you
>>>>
>>>> a. Try to run the test while passing --debug-configuration to bjam and
>>>>    send me the relevant output, and
>>>>
>>>> b. Try rolling back to the previous version of python.jam and see if
>>>>    that makes a difference?
>>>
>>> This request is a couple of days old. Is this still needed?
>> 
>> It wouldn't hurt, since so many tests are failing, to do at least step
>> a., and maybe step b., too.
>
> The output for gcc 4.1.0 on x86_64 can be found at 
> http://tinyurl.com/fpzg5 (268KB Text)

Probably my python.jam changes were involved.

  notice: looking for python 2.4
  notice: trying Python interpreter command python2.4
  notice: python2.4 invokes actual Python (major,minor) version 2.4
  notice: qualifying Python interpreter found
  notice: Python interpreter command is python2.4
  notice: Python include path is /usr/local/python/2.4/gcc-4.1.0/include/python2.4
  notice: Python library path is /usr/local/python/2.4/gcc-4.1.0/lib/python2.4/config

That means python2.4 will be invoked without any directory
qualification in order to run extension modules built against
/usr/local/python/2.4/gcc-4.1.0/include/python2.4/Python.h

>>> It seems that the different Python installations I use for testing 
>>> differ in some settings.
>
>>> Most of the tests fail for almost all Python installations I built 
>>> myself (the exception is icc 9.0).
>> 
>> All the failures seem to have the same symptom: the symbol
>> PyUnicodeUCS2_AsWideChar can't be found.  In turn, I'm betting that's
>> because the Python you're actually running was built with a different
>> Py_UNICODE_SIZE or Py_UNICODE_WIDE setting than the setting in your
>> Python.h.
>
> Hmm, I have no idea how the Python installation procedure could cause 
> this problem. Could there be a different (e.g. the system's) Python.h be 
> interfering? 

My guess is that the system's Python is interfering...

> If so then the -I flags would need to get rearranged.

...but that wouldn't be the right cure.  My guess is that the system's
Python is being invoked without qualification but the Python.h is for
your own Python.  Please try this patch to
tools/build/v2/tools/python.jam:



-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com