|
Boost Testing : |
From: David Abrahams (dave_at_[hidden])
Date: 2006-10-02 04:30:26
Martin Wille <mw8329_at_[hidden]> writes:
> David Abrahams wrote:
>> The following message is a courtesy copy of an article
>> that has been posted to gmane.comp.lib.boost.testing as well.
>>
>>
>> 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.
> It seems that the different Python installations I use for testing
> differ in some settings.
>
> x86 uses the system's (Gentoo's) Python for gcc 3.2.3 and gcc 3.3.6,
> a gcc 3.4.4 built Python installation for gcc 3.4.5, a gcc 4.0.0 built
> Python installation for gcc 4.0.3 and gcc 4.1.0, and an icc 9.0 built
> Python installation for icc 9.0.
>
> x86_64 uses the system's (Gentoo's) Python for everything except gcc
> 4.1.0. For gcc 4.1.0 there's a gcc 4.1.0 built Python installation.
>
> 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.
Unfortunately failed "run" test results no longer show the invocation
command, so it's hard to get all the info I'd like in order to debug
this.
-- Dave Abrahams Boost Consulting www.boost-consulting.com