[Python-Dev] Python Leopard DLL Hell

[Brian Cole]

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
>  > $DYLD_LIBRARY_PATH.
>  >
>  > 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
>