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

[Martin Panter]

Martin Panter added the comment:

Strictly speaking, Python 2.7 never had special support for RTLD_MEMBER or find_library(). That is why I am unsure about many of these changes being done in 2.7. They seem more like new features than bug fixes. Especially once you start talking about a smart CDLL() that tests for a file and then falls back to RTLD_MEMBER.

Whether you represent an archive member as an (archive, member) tuple, or as an "archive(member)" string, or something else, it is still an extension of the API of CDLL(), and arguably also of find_library().

I think I have already tried to explain that on Linux, find_library("libm.so") is far from normal usage (although may be technically legal if there was a library called liblibm.so.so).

Also, on Linux I wouldn’t recommend CDLL("libcrypt.so"), which relies on a file only intended for build time. On Debian, the glibc library <https://packages.debian.org/source/jessie/glibc> has separate packages for shared libraries (libc6) and development libraries (libc6-dev). It should be possible to run programs with libc6 installed, but without libc6-dev. Looking at the file lists for “i386” architecture, libc6-dev includes:

/usr/lib/i386-linux-gnu/libcrypt.a
/usr/lib/i386-linux-gnu/libcrypt.so

It symbolically links to /lib/i386-linux-gnu/libcrypt.so.1, which is provided by libc6:

/lib/i386-linux-gnu/libcrypt-2.19.so
/lib/i386-linux-gnu/libcrypt.so.1

So on Debian (and with Linux in general), CDLL("libcrypt.so") may work in some cases, but you should normally use CDLL("libcrypt.so.1") instead.

Usually people just upload a new version of the original patch (original changes, plus new changes, in one file). I think it would be too confusing looking at differences between two patches.

----------

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