[C++-sig] Re: Sharing Global Singleton instances across boost.python extensions (windows & unix)

[David Abrahams]

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> On 10 Oct 2003 at 19:56, David Abrahams wrote:
>
>> > You need not worry about POSIX shared objects because these behave
>> > more like a static library than DLL's do. But it is important not to
>> > have anything depend on special DLL functionality eg; DllMain.
>> 
>> Saying you need not worry is a bit too sanguine.  POSIX shared objects
>> have plenty of potential quirks, especially when it comes to dlopen'ed
>> ones like most Python extension modules.
>
> As do DLL's in Windows. If you've ever had the mispleasure of a DLL 
> faulting during initialisation, you'll know what I mean. Also, you 
> can't compare function pointers for equivalence if they're in a Win32 
> DLL etc. etc.

I wasn't claiming otherwise.

> Thing is, if you're porting to and only to very recent versions of 
> Linux there are very few non-obvious quirks nowadays.

Obviously you haven't been dealing with the same problems I've been
having in Boost.Python.  There are definitely some very subtle things
going on with weak symbols and templates; see
http://www.boost.org/libs/python/doc/v2/May2002.html#shared

>> On Linux the default for extending is that it's an executable and the
>> symbols get seen by extension modules.  For embedding, yes the default
>> is a static library.
>
> Don't suppose you know why this is Dave? I only found this out last 
> night and was quite puzzled by it not using a .so.

I think the extending configuration just makes distribution and
building simpler, but I'm really just guessing at the reasons.

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