https://svn.boost.org/trac10/ticket/10079 <p> 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: </p> <pre class="wiki"> # 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. </pre><p> 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. </p> <p> The obvious patch is as follows: </p> <pre class="wiki">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 ] : &lt;library&gt;/python//python_for_extensions ] + [ cond [ python.configured ] : &lt;library&gt;/python//python ] # we prevent building when there is no python available # as it's not possible anyway, and to cause dependents to </pre><p> However tools/build/v2/tools/python.jam says: </p> <pre class="wiki"> # 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. </pre><p> 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. </p> <p> 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. </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/10079 Trac 1.4.3