From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-03-22 04:57:50
can you comment on the below message?
The problem shows up not only for OSL2 but also for Martin, and I'd rather
implement the right solution, not one that happens to work with just the
Thanks in advance,
> The OSL2-V2 test results show a few link failiures for Python tests, for
> example the 'bases' test:
> Looks like Boost.Python library wants multi-threading for some reason. 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? The comment is not very clear, it
> seems it means static linking to Boost.Python, not statically linked
> application in the usual sense (no shared libs at all). The comment does
> not say why threading multi is needed.
> 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?
> 3. On my system, the test works just fine. Why does it fail elsewhere/
> 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.
> Can somebody explain this to me?
> Thanks in advance,
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk