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 <[email protected]>
<http://bugs.python.org/issue27435>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
