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 <[EMAIL PROTECTED]> 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 > -- http://mail.python.org/mailman/listinfo/python-list
