Repository navigation
CDLL does not use same paths as util.find_library #62702
Description
Activity
shjohnsonpi commented
on Jul 18, 2013 shjohnsonpimannequinMannequinAuthorCDLL does not use the same paths as find_library and thus you can *find* a library, but you can't necessarily use it.
In my case, I had SDL2 in /usr/local/lib. find_library correctly gets
the name, but does not return the path. CDLL apparently does not search
/usr/local/lib and fails.Python 3.4.0a0 (default:5a6cdc0d7de1, Jul 18 2013, 17:55:27) [GCC 4.7.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from ctypes import * >>> import ctypes.util >>> ctypes.util.find_library("SDL2") 'libSDL2-2.0.so.0' >>> CDLL(_) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/home/steven/Programming/cpython/Lib/ctypes/__init__.py", line 351, in __init__ self._handle = _dlopen(self._name, mode) OSError: libSDL2-2.0.so.0: cannot open shared object file: No such file or directory >>> CDLL("/usr/local/lib/libSDL2.so") <CDLL '/usr/local/lib/libSDL2.so', handle 22f89c0 at 7fc966da5ae8>
On Linux gcc and ld are used to implement 'find_library' and 'dlopen' is used to implement 'CDLL'. ld searches /usr/local/lib. 'dlopen' might not if the LD_LIBRARY_PATH isn't set up to do so. For example:
[meadori@li589-207 cpython]$ ls /usr/local/lib libfoo.so libfoo.so.1 libfoo.so.1.0 linode [meadori@li589-207 cpython]$ ./python Python 3.4.0a0 (default:d6213012d87b, Jul 23 2013, 01:00:24) [GCC 4.7.2 20120921 (Red Hat 4.7.2-2)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from ctypes import * >>> import ctypes.util >>> ctypes.util.find_library('foo') 'libfoo.so.1' >>> CDLL(_) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/home/meadori/src/cpython/Lib/ctypes/__init__.py", line 351, in __init__ self._handle = _dlopen(self._name, mode)OSError: libfoo.so.1: cannot open shared object file: No such file or directory >>> quit() [meadori@li589-207 cpython]$ echo $LD_LIBRARY_PATH [meadori@li589-207 cpython]$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib [meadori@li589-207 cpython]$ ./python Python 3.4.0a0 (default:d6213012d87b, Jul 23 2013, 01:00:24) [GCC 4.7.2 20120921 (Red Hat 4.7.2-2)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from ctypes import * >>> import ctypes.util >>> ctypes.util.find_library('foo') 'libfoo.so.1' >>> CDLL(_) <CDLL 'libfoo.so.1', handle 28e4b50 at 7f31e062b608>
I am OK with this behavior in ctypes since it matches the system behavior with 'gcc' and 'dlopen'. So, I would fixup LD_LIBRARY_PATH or /etc/ld.so.conf if you want /usr/local/lib to be searched at load time.
shjohnsonpi commented
on Jul 23, 2013 shjohnsonpimannequinMannequinAuthorShould the docs then be changed for find_library to inform that "It is not guaranteed that a found library can be opened" (at least for linux)?
Or would a feature request for full paths from find_library for linux be more appropriate?
It seems hackish to me, if a program can find a library, but can't use it without asking the user to change some environment variables or testing /usr/local/lib.
Documenting this quirk seems reasonable to me if you want to suggest a patch (and we don’t agree to fix it).
See bpo-21042 for returning full paths on Linux. We tried to make this change, but it wasn’t easy to do it consistently for arbitrary ABIs, so I backed it out.
See bpo-9998 discussing changing find_library() to emulate a run-time linker, rather than a compile-time linker.
I'm proposing to soft-deprecate
ctypes.util.find_library: https://discuss.python.org/t/106232It is now soft-deprecated, and the quirk is documented.
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields: