Re: [Boost-testing] OSL-V2 Python failures

From: Doug Gregor (dgregor_at_[hidden])
Date: 2006-06-27 12:14:02

Volodya,

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  
> different
> version.

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 darwin
   : 4.0.1
   ;

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:
/System/Library/Frameworks/Python.framework/Versions/2.3/bin/python2.3

v2 is using this Python executable:
/System/Library/Frameworks/Python.framework/Versions/2.3/bin/python

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  
linking return_arg_ext.so.

Index: python.jam
===================================================================
RCS file: /cvsroot/boost/boost/tools/build/v2/tools/python.jam,v
retrieving revision 1.12.2.4
diff -u -r1.12.2.4 python.jam
--- python.jam  4 Jun 2006 06:56:19 -0000       1.12.2.4
+++ 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) ;
      alias python_for_extensions
        :
@@ -241,7 +241,7 @@
        :
        : <os>MACOSX <toolset>darwin
        :
-      : <include>$(includes) <framework>$(PYTHON_FRAMEWORK)
+      : <include>$(includes) <linkflags>-F$(PYTHON_FRAMEWORK)  
<framework>Python
        ;
}

Because the <linkflags> don't seem to propagate in v2,  
return_arg_ext.so ends up linking against Python 2.4:

         /Library/Frameworks/Python.framework/Versions/2.4/Python  
(compatibility version 2.4.0, current version 2.4.0)

while v1 links against Python 2.3:

         /System/Library/Frameworks/Python.framework/Versions/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) ;
     #}

        Doug