[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

Martin Panter report at bugs.python.org
Sun May 8 02:29:33 EDT 2016


Martin Panter added the comment:

Your new patch calls find_library() internally in CDLL(); why? My understanding is CDLL() is a fairly lightweight wrapper around the dlopen() call. On Linux, you either pass a full library file name, or an SO-name. Both these strings can be discovered for compiled objects using e.g.:

$ ldd build/lib.linux-x86_64-2.7-pydebug/_ssl.so
	linux-vdso.so.1 (0x00007fff567fe000)
	libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007f598474c000)
	libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007f59842d4000)
	. . .

So in Python, the SO-name or full path can be used, but not the compile-time name, unless you first pass it through find_library():

>>> CDLL("libcrypto.so.1.0.0")  # soname
<CDLL 'libcrypto.so.1.0.0', handle 7f1665e1eb90 at 7f16658f34d0>
>>> CDLL("/usr/lib/libcrypto.so.1.0.0")  # Full path
<CDLL '/usr/lib/libcrypto.so.1.0.0', handle 7f1665e1eb90 at 7f1663cddcd0>
>>> CDLL("crypto")  # Compile-time name
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/ctypes/__init__.py", line 365, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: crypto: cannot open shared object file: No such file or directory
>>> find_library("crypto")  # Some people pass the result of this to CDLL()
'libcrypto.so.1.0.0'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________


More information about the Python-bugs-list mailing list