Boost Testing :
From: Doug Gregor (dgregor_at_[hidden])
Date: 2006-06-27 12:14:02
On Jun 19, 2006, at 4:28 AM, Vladimir Prus wrote:
> error message (see http://tinyurl.com/rdfse). It looks like the
> tests were
> built against one version of Python, while interpreter is of a
I think we're actually linking against a different version of Python
than we build with...
> In theory, python.jam has the code to prefer Python intepreter from
> the same
> location where libraries are found, but maybe that does not work
> due to
> different directory layout on OSX.
> If you have a moment, can you send me this information:
> 1. Your user-config.jam
This is it:
using python : 2.3 ;
> 2. Where's 'python' binary can be found, relatively to the 'root'
> that use
> specify in 'using python'. If you don't specify root, can you see what
> 'python' executables are available on the system.
v1 is using this Python executable:
v2 is using this Python executable:
The executables appear to be identical, have identical behavior, etc.
I don't think this is the issue.
> 3. Can you do to libs/python/test directory and run one of the
> failing test
> manually with -n, and sent me the produced command lines?
Yep. I've attached return_arg.v1 and return_arg.v2, so we can see the
differences between v1 (which works fine) and v2 (which doesn't). I
found a couple interesting differences. First, I realized that the
handling of "-framework" wasn't quite right. Like link paths (-L) and
link commands (-l), frameworks are split into framework paths (-F/
System/Library/Frameworks) and framework commands (-framework
Python). The tiny patch below almost makes this work, but the
<linkflags> don't seem to get propagated to the command line when
RCS file: /cvsroot/boost/boost/tools/build/v2/tools/python.jam,v
retrieving revision 184.108.40.206
diff -u -r220.127.116.11 python.jam
--- python.jam 4 Jun 2006 06:56:19 -0000 18.104.22.168
+++ python.jam 27 Jun 2006 15:49:24 -0000
@@ -228,7 +228,7 @@
PYTHON_FRAMEWORK = $(PYTHON_FRAMEWORK:D) ;
- PYTHON_FRAMEWORK = $(PYTHON_FRAMEWORK:D)/Python ;
+ PYTHON_FRAMEWORK = $(PYTHON_FRAMEWORK:D) ;
@@ -241,7 +241,7 @@
: <os>MACOSX <toolset>darwin
- : <include>$(includes) <framework>$(PYTHON_FRAMEWORK)
+ : <include>$(includes) <linkflags>-F$(PYTHON_FRAMEWORK)
Because the <linkflags> don't seem to propagate in v2,
return_arg_ext.so ends up linking against Python 2.4:
(compatibility version 2.4.0, current version 2.4.0)
while v1 links against Python 2.3:
Python (compatibility version 2.3.0, current version 2.3.5)
Tracing it back a little ways, the same thing happens with
libboost_python-whatever.dylib: it gets built against the Python 2.3
headers, but links against Python 2.4.
There is also some very fishy code in python-extension, which
probably accounts for the fact that v2 is linking with "-dynamiclib"
instead of "-bundle".
# TODO: handle the following V1 code
#if $(OS) = MACOSX && $(toolset) = darwin
# if <target-type>PYD in $(properties)
# properties += <link-format>bundle ;
# properties += <framework>$(PYTHON_FRAMEWORK) ;