Martin Panter added the comment:
Thanks for trying to move the directory in the new patch, but it does not seem
to have been picked up by Rietveld. I have only seen patches generated with
Mercurial and Git work, but I don’t exactly know _why_ they work :)
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)
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.
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 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.
3. find_library() should not set the LIBPATH environment variable.
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue26439>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
