From: David Abrahams (dave_at_[hidden])
Date: 2006-07-12 18:44:17
At least, that's the only conclusion I can draw from:
We used to use this rule:
# 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 in the v2 toolset I see:
# - There was 'python-static-multithread' logic. Don't know
# what it affected, so can't test.
I don't know what that means. Clearly from the v1 comment it affected
statically-linked embedding applications on Unix.
Failure to reproduce this behavior is clearly the problem with the
'exec' test and several others as well.
I also note this:
# - V1 had logic to force intel to use gcc's runtime.
# Note sure why that was needed, with icc 8.0 extensions
# built with intel are loaded by python without problems.
Has the version of Python also been built with Intel? If so you won't
see any problems, as the following v1 comment indicates:
# Normally on Linux, Python is built with GCC. A "poor QOI choice"
# in the implementation of the intel tools prevents the use of
# intel-linked shared libs by a GCC-built executable unless they
# have been told to use the GCC runtime. This rule adds the
# requisite flags to the compile and link lines.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk