Re: [Boost-build] CVS: boost/tools/build/v2/tools python.jam, 1.30, 1.31

From: David Abrahams (dave_at_[hidden])
Date: 2006-08-31 08:35:06

Vladimir Prus <ghost_at_[hidden]> writes:

> On Thursday 31 August 2006 00:56, David Abrahams wrote:
>> Update of /cvsroot/boost/boost/tools/build/v2/tools
>> In directory sc8-pr-cvs3.sourceforge.net:/tmp/cvs-serv4741
>>
>> Modified Files:
>> 	python.jam
>> Log Message:
>> Fix QNX's dependency on pthread (which doesn't exist on those systems).
>> Clean up the comments a bit.
>>
>>
>> Index: python.jam
>> ===================================================================
>> RCS file: /cvsroot/boost/boost/tools/build/v2/tools/python.jam,v
>> retrieving revision 1.30
>> retrieving revision 1.31
>> diff -u -d -r1.30 -r1.31
>> --- python.jam	25 Aug 2006 07:22:22 -0000	1.30
>> +++ python.jam	30 Aug 2006 20:56:26 -0000	1.31
>> @@ -139,22 +139,12 @@
>>
>>      switch [ os.name ]
>>      {
>> -        case SOLARIS : extra-libs = dl      ;
>> -        case OSF :     extra-libs =         ;
>> -        case QNX* :    extra-libs =         ;
>> -        case * :       extra-libs = dl util ;
>> +        case SOLARIS : extra-libs = pthread dl      ;
>> +        case OSF :     extra-libs = pthread         ;
>> +        case QNX* :    extra-libs =                 ;
>> +        case * :       extra-libs = pthread dl util ;
>>      }
>>
>> -    # Depending on system, Python library is either static
>> -    # or shared. When it's static, we need to add 'pthread'
>> -    # to link line of all clients, otherwise we'll get
>> -    # unresolved symbols. Same effect can be accomplished
>> -    # by using <threading>multi on the client, but
>> -    # that can have performance overhead, and is not really
>> -    # necessary, as Python interface has nothing that's
>> -    # affected by threading mode.
>
> I assume that this comment was deleted by mistake? It captures quite some 
> discussion we had, so I'm about to put it back.

Hmm, I had some problems with it and it seemed out of place once I had
no special section just for -lpthread.  It certainly is wrong even for
some platforms that use a static python library (QNX), and it seems to
incorrectly imply that there's only either a dynamic or a static
python library, but not both, on any given platform. Now that I look
at it, though, I realize that it does capture something useful.  I
propose this replacement, above the switch:

    # Provide system library dependencies for static Python libraries.
    # Static libraries carry no library dependency information of
    # their own that the linker can extract, so library dependencies
    # have to be given explicitly on the link line of the client.  
    # package the information into the "python" target below.
    #
    # Even where Python itself uses pthreads, it never allows
    # extension modules to be entered concurrently (unless they
    # explicitly give up the interpreter lock).  Therefore,
    # extension modules don't need the efficiency overhead of
    # threadsafe code as produced by <threading>multi, and we
    # handle libpthread along with other libraries here.

Whew, _that_ took a long time to write!

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