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 <rep...@bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to