[Python-Dev] Python Leopard DLL Hell (original) (raw)

Brian Cole brianc at temple.edu
Wed Apr 9 19:36:38 CEST 2008

I have learned that this is a specific behavior of OS X. I have submitted a formal bug report to Apple about the problem. It appears that this is documented by Apple as acceptable: http://developer.apple.com/documentation/DeveloperTools/Reference/MachOReference/Reference/reference.html#//apple_ref/c/func/dlopen

Whereas, linux will respect the fact you gave it a specific shared library: http://linux.die.net/man/3/dlopen

If I am provided a workaround by apple I will post a python patch. A little scary that someone can circumvent my application by just setting an environment variable.

-Brian Cole

On Tue, Apr 8, 2008 at 7:52 PM, Michael Torrie <torriem at gmail.com> wrote:

Brian Cole wrote: > That appears to be working correctly at first glance. The argument to > dlopen is the correct shared library. Unfortunately, either python or > OS X is lying to me here. If I inspect the python process with OS X's > Activity Monitor and look at the "Open Files and Ports" tab, it shows > that the foo.so shared library is actually the one located inside > $DYLDLIBRARYPATH. > > So this problem may not be python's, but I place it here as a first > shot (maybe I'm using the imp module incorrectly).

Sounds like you're going to need to learn how to use dtrace. Then you can more closely monitor exactly what python and the loader are doing. dtrace is very complicated (borrowed from Solaris) but extremely powerful. Worth learning anyway, but sounds like it's probably the debugging tool you need. Another thing you can do is check through the python source code and see how the os x-specific code is handling this type of situation. -- http://mail.python.org/mailman/listinfo/python-list

More information about the Python-Dev mailing list