[Boost-bugs] [Boost C++ Libraries] #10079: libboost_python DSO should link to libpython

Subject: [Boost-bugs] [Boost C++ Libraries] #10079: libboost_python DSO should link to libpython
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2014-05-29 18:11:00

#10079: libboost_python DSO should link to libpython
------------------------------+---------------------
 Reporter:  pmachata@…        |      Owner:  rwgk
     Type:  Bugs              |     Status:  new
Milestone:  To Be Determined  |  Component:  Python
  Version:  Boost 1.55.0      |   Severity:  Problem
 Keywords:                    |
------------------------------+---------------------
 Shared libraries for Boost.Python are not linked to Python shared
 libraries.  libs/python/build/Jamfile.v2 contains the following
 explanation why that's so:
 {{{
             # On *nix we never link libboost_python to libpython.  When
             # extending Python, all Python symbols are provided by the
             # Python interpreter executable.  When embedding Python, the
             # client executable is expected to explicitly link to
             # /python//python (the target representing libpython) itself.
 }}}

 I especially wonder about the "executable is expected to explicitly link"
 bit.  Where does this expectation come from?  On Linux it is generally
 business of the library to care about its own dependencies.  Python is
 probably something of a borderline case in this, as a Boost.Python client
 presumably knows they will interface with Python eventually.  Still, it is
 possible to create a Boost.Python client without mentioning any of Python
 per se.  Thus linking in libboost_python should be all that's necessary.

 The obvious patch is as follows:
 {{{
 diff -up boost_1_55_0/libs/python/build/Jamfile.v2\~
 boost_1_55_0/libs/python/build/Jamfile.v2
 --- boost_1_55_0/libs/python/build/Jamfile.v2~  2010-07-13
 00:29:41.000000000 +0200
 +++ boost_1_55_0/libs/python/build/Jamfile.v2   2014-05-29
 19:16:31.238412843 +0200
 @@ -122,7 +122,7 @@ rule lib_boost_python ( is-py3 ? )
              # python_for_extensions is a target defined by Boost.Build to
              # provide the Python include paths, and on Windows, the
 Python
              # import library, as usage requirements.
 -            [ cond [ python.configured ] :
 <library>/python//python_for_extensions ]
 +            [ cond [ python.configured ] : <library>/python//python ]

              # we prevent building when there is no python available
              # as it's not possible anyway, and to cause dependents to

 }}}

 However tools/build/v2/tools/python.jam says:

 {{{
     # On *nix, we do not want to link either Boost.Python or Python
 extensions
     # to libpython, because the Python interpreter itself provides all
 those
     # symbols. If we linked to libpython, we would get duplicate symbols.
 So
     # declare two targets -- one for building extensions and another for
     # embedding.
 }}}

 Do you know any details about the duplicate symbol issue?  I track this
 code down to a commit from Mon Dec 6 14:03:25 2004 by Vladimir Prus, but
 the commit message doesn't explain anything.

 On Linux at least, there's no problem bringing in a dynamic library
 "several times".  Even with static libraries it's not clear to me how the
 duplication would occur.  But possibly I'm missing something obvious.  I
 can however make the above patch sensitive to OS if you think the issue is
 real on other systems.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/10079>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.