From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-07-22 03:13:45
On Saturday 22 July 2006 10:32, Vladimir Prus wrote:
> > Yes, it's problematic. On Unix, dynamically loaded python extensions
> > get the python symbols from the executable. If we're extending
> > Python, then that's the python executable itself. If we're embedding
> > Python, it's the embedding application, which is supposed to be linked
> > to libpython.a
> Yep, we'll end up with two copies of symbols, but is this going to cause
> real problems?
> Anyway, I'll try to change this. That raises, again, this question: Do we:
> - Document that for embedding, application should be explicitly linked
> to Python
> - Add new target "boost_python_for_embedded", that will alias to
> Boost.Python, Python, and any auxilliary libraries.
> I'm fine with just adding /boost/python to all embedding applications, as
> far as tests are concerned. You know better, though.
I've just checked in the attached. Let me know if something looks wrong.
Don't link Boost.Python to python library, and don't require
<threading>multi for embedding applications.
* libs/python/build/Jamfile.v2: (boost_python): Don't link
to /python//python. Use /python//python_for_extensions.
* libs/python/test/Jamfile.v2: Remove <threading>multi project
(py-run): Link to /python//python.
* tools/build/v2/tools/python.jam: (pthread): Declare.
(init-unix): Add 'pthread' to extra-libs.
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