Re: [boost] [python] threading-related failures on Linux

From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-03-22 10:48:54

David Abrahams wrote:

>> Looks like Boost.Python library wants multi-threading for some
>> reason.
> 
> It's not just -lpthread, but also -ldl that is missing.

The 'dl' is already added in CVS, we've talked with Martin about it and
figured out that on some Unixes Python links to dl and on others don't.

>> In V1, those tests are linked with -pthread, and in V2, they are
>> not. The logic responsible for this in V1 is in python.jam:
>>
>>     # Force statically-linked embedding applications to be multithreaded
>>     # on UNIX.
>>     rule python-static-multithread ( toolset variant : properties * )
>>     {
>>         if ! $(PYTHON_WINDOWS)
>>         {
>>             local x = <define>BOOST_PYTHON_STATIC_LIB <threading>single ;
>>             if $(x) in $(properties)
>>             {
>>                 properties = [ difference $(properties) :
>>                 <threading>single ]
>>                                 <threading>multi ;
>>             }
>>         }
>>         return $(properties) ;
>>     }
>>
>> And I don't understand some things:
>>
>> 1. What's the point of this at all?
> 
> It made things work :)
> 
> IIRC, libpythonXX.a on *nix requires these libraries.  Why is this
> mysterious?

Why it requires -pthread only whem <define>BOOST_PYTHON_STATIC_LIB is in
properties. Everything else is not a mistery.

>> The comment is not very clear, it seems it
>> means static linking to Boost.Python,
> 
> Yes.
>> not statically linked application in the usual sense (no shared libs
>> at all). The comment does not say why threading multi is needed.
> 
> There are two usual ways to use Python on *nix:
> 
> 1. extending, where the Python executable dynamically loads Python
>    extension modules and they use the Python API that's statically
>    linked into the Python executable.  In this model, the Python
>    executable is linked to whatever libraries it needs, such as
>    pthreads and dl.
> 
> 2. embedding, where a user-written executable uses the Python API in
>    libpythonXX.a.  In that case, who is going to link to pthreads and
>    dl if not the user-written executable.

Then, how <define>BOOST_PYTHON_STATIC_LIB is related to those cases. It's
quite feasible to embed python and use shared linking to Boost.Python at
the same time.

>> 2. In V2, shared linking to Boost.Python is used, and the
>> application is fully shared. So, where does the link error come
>> from? Is comment even more inaccurate?
> 
> Than what?

I mean, -pthread is required for all embedding, even if linking to
Boost.Python is shared. Right?

>> 4. The test in question, bases.cpp, has nothing but static asserts. It's
>> not clear to me why it should link to Boost.Python at all.
> 
> In this case you could probably turn it from a "run" test into a
> "compile" test, then.

Ok.

Thanks for explanation. I'll think about best way to distinguish between
extending and embedding.

- Volodya