This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author martin.panter
Recipients David.Edelsohn, Michael.Felt, martin.panter
Date 2016-05-08.06:29:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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/ (0x00007fff567fe000) => /usr/lib/ (0x00007f598474c000) => /usr/lib/ (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("")  # soname
<CDLL '', handle 7f1665e1eb90 at 7f16658f34d0>
>>> CDLL("/usr/lib/")  # Full path
<CDLL '/usr/lib/', 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/", 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()
Date User Action Args
2016-05-08 06:29:33martin.pantersetrecipients: + martin.panter, David.Edelsohn, Michael.Felt
2016-05-08 06:29:33martin.pantersetmessageid: <>
2016-05-08 06:29:33martin.panterlinkissue26439 messages
2016-05-08 06:29:33martin.pantercreate