[Boost-build] v2 Python toolset doesn't faithfully reproduce v1

From: David Abrahams (dave_at_[hidden])
Date: 2006-07-12 18:44:17

At least, that's the only conclusion I can draw from:

http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/output/Martin%20Wille%20V2-boost-bin-v2-libs-python-test-bases-test-gcc-3-4-5_linux-debug_release.html

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:

    # NOTES:
    # - 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