[python-committers] The state of our copies of libffi (was: Redoing the C API?)

[Matthias Klose]

On 03.03.2016 21:58, Zachary Ware wrote:
> On Thu, Mar 3, 2016 at 12:38 PM, Brett Cannon <brett at 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