[Fwd: Re: [Pythonmac-SIG] OS X import bug?]

[Manoj Plakal]

Jack Jansen wrote:

> 
> On Saturday, January 26, 2002, at 01:53  PM, Marcel Prastawa wrote:
> 
>> Out of curiosity, is the 'identical binary name' problem with 
>> dynload_next a MacPython problem (that we could work out) or is it a 
>> problem with the OS X framework?
> 
> 
> My feeling is that the problem is with dynload_next.c, which is a very 
> old file that hasn't seen any development for many years (between NeXT's 
> near-demise and OSX's appearance). The problem is exacerbated by the 
> fact that the APIs used in dynload_next.c or very poorly documented, if 
> at all. My guess (can anyone confirm this or point me to more info?) is 
> that the NSIsSymbolNameDefined() call at the beginning is incorrect, and 
> will return the wrong module upon import of a second module with the 
> same name.
> 
> Maybe someone who is experiencing the problem can comment out that 
> quick-return section and see whether dynload_next.c then works as 
> expected? Or will we then immedeately run into flat namespace problems 
> (two routines called initfoo)?

           There's some documentation from Apple:
           http://developer.apple.com/techpubs/macosx/ReleaseNotes/TwoLevelNamespaces.html
           Also man NSModule, man NSObjectFileImage, man 3 dyld ...

	  Is there a "reference implementation" of loading extensions
           against which we can compare the dynload_next.c file to
           see if it is implementing the official semantics?

           Manoj