From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-07-22 02:32:47
On Thursday 13 July 2006 22:30, David Abrahams wrote:
> Vladimir Prus <ghost_at_[hidden]> writes:
> > On Thursday 13 July 2006 20:05, David Abrahams wrote:
> >> Vladimir Prus <ghost_at_[hidden]> writes:
> >> > On Thursday 13 July 2006 18:09, David Abrahams wrote:
> >> >> Vladimir Prus <ghost_at_[hidden]> writes:
> >> >> > We've being though this before, and you basically agreed that this
> >> >> > comment is not accurate. Please see the attached message. This
> >> >> > topic then died.
> >> >>
> >> >> Do we need it to un-die, or do you think all the problems are
> >> >> resolved?
> >> >
> >> > I think we need it to un-die. The two current issues are:
> >> >
> >> > 1. I've modified Boost.Python tests Jamfile.v2 to have
> >> > <threading>multi. I think that fixes the errors, but is not a clean
> >> > solution. I'd prefer direct linking to pthread.
> >> Why? For example, do you believe the other options that
> >> <threading>multi might add are inappropriate, and if so, why do you
> >> think that?
> > The apparent problem we see that that Python wants symbols from the
> > pthread library. The apparent solution is to add that library.
> I would say the right solution is to declare
> lib pthread;
> lib python : : : <source>pthread ;
> or however it is you get pthread into the usage requirements for libpython.
Yes, that's precisely what I wanted.
> > The <threading>multi, applied to my main executable, means I pay for
> > thread safety, even if my executable is single-threaded.
> I agree as long as you are convinced that there's no link
I'm 99% sure.
> >> > 2. I noticed that in V2 Boost.Python links to Python library.
> >> Too vague to understand.
> > On Unix, the Boost.Python's so library is created, there's
> > -lpython2.3 option on linkers' command line. This in in V2, and in
> > V1 this is not done.
> Okay. Do you know why it's done in v2, and who did it?
I did, the log message for revision 1.8 of build/Jamfile.v2 is unfortunately
not very descriptive.
> >> > This sounds potentially problematic, I'm not sure if Python
> >> > interpreter will completely hide all symbols from Python shared lib.
> >> Sorry, you lost me completely here. Whose symbols? How would a
> >> Python interpreter hide symbols?
> > Python interpreter has almost the same set of functions as Python dynamic
> > library (the Py_* functions). If Python interpreter loads an extension
> > which links to Boost.Python which is linked to Python library, you get
> > two copies of each function. And I have no idea if this is going to work,
> > or create some problems.
> 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
Anyway, I'll try to change this. That raises, again, this question: Do we:
- Document that for embedding, application should be explicitly linked to
- 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.
-- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build V2: http://boost.org/boost-build2
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