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

From: David Abrahams (dave_at_[hidden])
Date: 2006-03-22 09:05:07

Vladimir Prus <ghost_at_[hidden]> writes:

> The OSL2-V2 test results show a few link failiures for Python tests, for 
> example the 'bases' test:
>
>     http://tinyurl.com/nyqv7

Isn't this just the same issue we've seen several times: the
Jamfile.v2 fails to properly translate the v1 logic (in this case
leaving out the effects of <template>py-unit-test)?

> Looks like Boost.Python library wants multi-threading for some
> reason. 

It's not just -lpthread, but also -ldl that is missing.

> 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?

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

> 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?

> 3. On my system, the test works just fine. Why does it fail elsewhere/

Different unices and Python builds have slightly different requirements.

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

> Can somebody explain this to me?

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