[Pythonmac-SIG] Re: dynload_next patch - still waiting for feedback

[Manoj Plakal]

Marcel Prastawa wrote:
> Manoj wrote:
>>> Wouldn't it be better to shift the responsibility
>>> to the module building phase: a change to
>>> distutils which changes the link options between
>>> flat or 2-level? Keep it 2-level by default,
>>> and only those modules which absolutely need flat
>>> can specify an extra distutils option.
>>
> Jack wrote:
>> That's what I thought too, but somehow it doesn't work that way. I 
>> think that for a plugin the global symbols in the plugin are in the 
>> "toplevel" namespace, so if you load the plugin into the application 
>> global namespace all symbols from the plugin will appear in the global 
>> namespace.
>>  Symbols that the plugin references from other dynamic libraries 
>> probably won't (but I didn't try this), but our real problem is the 
>> plugin initxx(
>> ) routine which conflicts with the initxx() routine from a different 
>> module.
> 
> 
> To my knowledge, with two-level namespaces, we won't face any problems 
> with undefined symbols and namespace clashes, even with the initxx() 
> functions. Unfortunately, porting UNIX applications to OS X with 
> two-level namespaces can be quite burdensome. So, if possible, I think 
> that the dynamic loader should have some mechanisms to deal with flat 
> namespace issues.


             I agree with Marcel.

             Based on my little knowledge of OS X linking gleaned
             from Apple's docs, it seems to me that 2-level namespaces
             provide the right behavior for Python modules, and
             this is behavior consistent with other platforms too.

             The only problem, as Marcel pointed out, is that
             2-level namespaces require all external references
             to be resolved at compile time, which is a burden
             for some modules like VTK. Flat namespaces don't
             have this problem but then symbols clash across modules.

             How about leaving it as 2-level namespace by
             default, and then telling module authors (or builders)
             that as a special case on OS X, if their module
             does not build by default, they should choose
             the flat namespace option and write a small
             Python stub that fiddles with dlopenflags before
             importing the real extension module? This
             will work for things like VTK, won't it?
             User program stay unaffected, and this can
             just be some extra distutils options on OS X.

             Manoj