[Pythonmac-SIG] dlopenflags and sharing symbols across python extension modules

[Zachary Pincus]

Thanks for your feedback, Bob.

>> I don't have access to a 10.2 machine currently, so if someone is  
>> able to test this patch on 10.1, 10.2, and/or 10.3, I would be  
>> most grateful. I can try to find some 10.2 install disks (and hope  
>> that my computer can run 10.2) if nobody has easy access to such a  
>> machine.
>
> I think the Mac OS X box on the sourceforge compile farm may be 10.2.

Now, assuming the configure script works right, things aren't  
changing on the 10.2 case. So all that's needed to test there is that  
dynload_next and not dynload_shlib is picked up in the configure step.

This would be very easy to test for anyone who has a 10.2 box, since  
it doesn't actually involve compiling anything. I'll look into using  
the sourceforge one.

However, on 10.3, this patch actually changes the behavior to use  
dynload_shlib (same on 10.4). I've tested it on 10.4, but we ought to  
make sure that things work on 10.3 too. Does anyone have access to a  
10.3 box?


>> One last thing -- given that OS X now has dlfcn.h and dlopen(),  
>> will the library dl module now work? Right now, setup.py won't  
>> build dlmodule.c on darwin, even if it can find dlfcn.h. Does  
>> anyone know the reason for this is still valid for 10.3 or 10.4?
>
> That module should be available on 10.3+ (but isn't, obviously),  
> but it's not all that useful on its own.  I'd just use ctypes  
> instead, especially since it's slated for inclusion with Python 2.5.

I'm going to branch this discussion to a new email thread to see if  
anyone else has any thoughts. The main argument for having dl work on  
the mac (other than the fact that it is a part of the standard  
library!) is that if sys.setdlopenflags() is respected, there should  
be some in-python way to get the appropriate flags (which are  
different on darwin's dlfcn.h than on most other platforms). And  
these flags are defined in the dl module.

Zach