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

From: David Abrahams (dave_at_[hidden])
Date: 2006-07-13 14:30:19

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.

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

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

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

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com