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
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~ 2010-07-13
+++ boost_1_55_0/libs/python/build/Jamfile.v2 2014-05-29
@@ -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
# import library, as usage requirements.
- [ cond [ python.configured ] :
+ [ 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
# to libpython, because the Python interpreter itself provides all
# symbols. If we linked to libpython, we would get duplicate symbols.
# declare two targets -- one for building extensions and another for
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.
This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:16 UTC