Re: [Boost-build] v2 Python toolset doesn't faithfully reproduce v1

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
> incompatibility.

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 
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.

- Volodya

-- 
Vladimir Prus
http://vladimir_prus.blogspot.com
Boost.Build V2: http://boost.org/boost-build2