On 03.03.2016 21:58, Zachary Ware wrote:
On Thu, Mar 3, 2016 at 12:38 PM, Brett Cannon <br...@python.org> wrote:
[...] the maintenance issue we have with ctypes (or at least that's
my hang-up with it). I think we still have not figured out what code we have
patched and so no one has been willing to update to a newer version of
libffi. I think Zachary looked into it and got some distance but never far
enough to feel comfortable with trying to update things.
Since I've been invoked, I'll try to explain our libffi situation as
far as I understand it. This is just a history lesson, I don't really
have an opinion on what should be done with it. I will opine that we
have some seriously old unmaintained code here, and the whole libffi
situation in cpython is far more complex than is ideal.
We actually have four separate copies of libffi:
Modules/_ctypes/libffi: This is a mostly-vanilla copy of libffi-3.1
(released 19May2014), lightly patched according to
Modules/_ctypes/libffi.diff. This one is used for any non-OSX posix
build that doesn't use `--with-system-ffi`. doko has done a pretty
good job keeping this one relatively up to date.
when trying to update these extra copies, I was always told that upstream was
wrong/not ready, etc ... So I don't care that much about the copies. The
explicit diff was intended to document the explicit and wanted changes.
Now, the last libffi release 3.2.1 is more than a year old, and getting outdated
for some architectures. Upstream currently doesn't react, and the libffi copy
within GCC is ahead with many changes. My plan was to update libffi with a 3.3
release when it comes out, but I don't know when this will happen.
Matthias
_______________________________________________
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/
