LD_LIBRARY_PATH is ignored by dlopen()

Issue #219 new
Kuldeep Singh Dhaka
created an issue



so, since ctypes.util.find_library ignore LD_LIBRARY_PATH, there is no way to open libraries from non-standard path (on unix). [not tested on windows]

[my usecase: im developing a c library and while in development mode, i have to install it somewhere in my home directory]

possible workaround, ffi.dlopen("libmywork.so") work for GNU/Linux. for, Microsoft Windows, ffi.dlopen("libmywork.dll") [should work]

related: #58

Comments (2)

  1. Armin Rigo

    A careful reading of https://docs.python.org/2/library/ctypes.html#finding-shared-libraries shows that find_library("foo") is supposed to work like the gcc option -lfoo, which ignores LD_LIBRARY_PATH. There is however no equivalent to the gcc option -Lpath to specify the search path.

    The whole issue is messy. For example, the naming conventions mean that a library might be called "libmywork.so.2" on Linux, "libmywork.dylib" on OS/X, but "mywork.dll" on Windows (and not "libmywork.dll"). But that's not universally true.

    Here is a more precise summary of what ctypes.util.find_library(name) does. (This post does not contain any conclusion or answer about what we should do, it just describes the situation.)

    On Windows: search along the PATH for a file called name or name.dll. (That's the only platform on which the algorithm can be nicely explained in one sentence.)

    On OS/X: search for libname.dylib, name.dylib and name.framework/name. For each one, the complex logic of dyld seems to be emulated in pure Python. It looks up a number of environment variables starting with DYLD_, including DYLD_LIBRARY_PATH but also many others (but not LD_LIBRARY_PATH).

    On the BSDs: calls /sbin/ldconfig -r to get the list of all libraries that can be found. Then uses regexps to locate the correct one in the list. Returns the one with the highest version number, if there are several. If not found, fall back to _findLib_gcc (see below).

    On SunOS5: ... (I'm going to ignore this one)

    On Linux: calls /sbin/ldconfig -p and does something similar to BSD except there is no version number resolution code---I guess ldconfig does that for us in this case.

    Finally, the fall-back case is the _findLib_gcc() function, which calls gcc and objdump in some way I don't really want to understand, probably to figure out what gcc itself thinks about the -lname option.

  2. Log in to comment