Martin Panter added the comment:
.
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.
----------
versions: +Python 3.6 -Python 2.7, Python 3.4, Python 3.5
_______________________________________
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
