.
Michael, how are you supposed to apply your latest patch? I have Gnu Patch 2.7.5, but even in the best case it doesn’t find the files to patch:

$ patch -p1 -n < python.Lib.ctypes.160608.patch
can't find file to patch at input line 2
The text leading up to this was:
--------------------------
|diff -r Python-2.7.11/Lib/ctypes/__init__.py python-2.7.11.5/Lib/ctypes/__init__.py
--------------------------

Perhaps can you make a “unified” diff (-u option) like you did in your previous patches? Whatever you did with Python3.issue26439.160511.patch seemed to work best.

Also, since your patches add new functionality (the automatic archive member detection), they will have to be for Python 3, not 2.

===

Tuple vs "archive(member)" string being an API change:
> name = "libcrypto.a(libcrypto.so.1.0.0)"
> name = ("libcrypto.a", "libcrypto.so.1.0.0")
> name = ("libcrypto.a(libcrypto.so.1.0.0)", RTLD_MEMBER)

IMO all three options are API changes. Even though the first one is still a string, we are changing the meaning of the string. It no longer always means a plain file or library name, and you lose the ability to indicate a plain library file when the special format is used (even though that ability is unlikely to be used much).

===

Yes, please remove the internal variables from the signatures. Local variables always override the global scope anyway, so it makes no difference. And if you use the wrong kind of object (mutable object) as a default value in the signature, it can actually lead to subtle bugs.

I am happy to try modifying your code (once we get the patch format etc figured out). That is probably the quickest way to fix up some of the problems that are obvious to me, e.g. variables in signatures, subprocess driving, etc.

===

With my understanding, find_library("FOO") should not recognize /usr/lib/FOO.so, it should only look for /usr/lib/libFOO.so, etc. So it should return None. Does linking with -lFOO recognize /usr/lib/FOO.so for you?

Similarly, find_library("../some/where/Foo.so") shouldn’t work. You wouldn’t pass that with -l to the linker, I don’t think.