> FYI: I tried to pip install Mercurial - but got an error message from an include file so the last bit did not compile. Problem for a later date - could be a user error on my part, or an AIX version dependency. (during discussion issue26439)

I have mercurial "installed", but not (yet) any idea on how to use it to submit a patch.

Again: going back to comments in issue26439 - and my 'new' responses as far as the patch submitted (but not yet using Mercurial)

> Here is a summary of what I would be comfortable adding to Python:

> 1. Add ctypes.RTLD_MEMBER constant (new API, so 3.6+ only)

Not included. RTLD_MEMBER is a well documented constant needed for AIX dlopen. It is hard-coded in __init__.py

> 2. Basic ctypes.util.find_library("crypto") implementation for AIX. But cases like find_library("libintl.so") should fail. I think your earlier patches were closer to this implementation than the later ones.

Months further, I understand that is a variant behavior, and has been removed. find_library("c"), find_library("crypto") are supported, an argument suchas find_library("libintl.so") will return None (or something like /usr/lib/liblibintl.so will need to exist).

> I am a bit hesitant about the automatic behaviour of CDLL("libcrypto.a(libcrypto.so.1.0.0)") using RTLD_MEMBER. IMO it may be better to let the caller specify RTLD_MEMBER explicitly. If a shared library file literally called “/usr/lib/libcrypto.a(libcrypto.so.1.0.0)” existed, i.e. not inside an archive, would dlopen("libcrypto.a(libcrypto.so.1.0.0)", RTLD_NOW) succeed? I admit this is an unlikely scenario, but it seems bad to reduce the domain of a low-level API.

>I hope this is now acceptable (see http://bugs.python.org/issue26439#msg267254) 
>> ## Automatic RTLD_MEMBER ##

>I was still uneasy about the automatic setting of RTLD_MEMBER. But I looked for how others handle this, and I found Libtool’s LTDL library, and Apache Portable Runtime (APR). Both have a similar (but stricter) automatic addition based on detecting the archive(member) notation:

>http://git.savannah.gnu.org/cgit/libtool.git/commit/libltdl/loaders/dlopen.c?id=8fa719e
>https://github.com/apache/apr/commit/c27f8d2

> So I guess I can accept this way,

> I understand it would be good to have the return value of find_library() consistent with the name accepted by CDLL(). Perhaps a new parameter format would help, such as a tuple (archive, member).

> I am not comfortable with other aspects. I think I would have to see more discussion with other people to change my opinion:

> 1. CDLL("libintl.so") should not load “libintl.a(libintl.so.1)”. I understand you want this to help code written for Gnu or Linux automatically work on AIX, but it doesn’t feel correct and robust to me. Perhaps moving this sort of thing to a separate function or package would be better.

> 2. find_library("libintl.so") -> "libintl.a(libintl.so.1)". I would expect it to look for a shared library installed in something like "/usr/lib/liblibintl.so.a", unless I have misunderstood how compile-time linking (cc -llibintl.so) works.

Again, my misunderstanding of how this function is intended - python newbie. arguments starting with "lib" are not likely to work - and it is not on find_library to strip "lib" to make the argument more -l like.

> 3. find_library() should not set the LIBPATH environment variable.

As before, and as is the status in issue9998 - no use of LIBPATH or LD_LIBRARY_PATH - even though dlopen() does use them. Although, if your objection is primarily on 'set' (i.e., a get could be accepted) - that is easy to put back in.

Thanks again for your help.

Note: the reason for the new issue# is because too much of what I was submitting before was "extension" and not "correction".

Hopefully, this makes the discussion more clear.