Michael Felt added the comment: > 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27435> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com