[Python-Dev] libffi embedded in CPython

Jim J. Jewett jimjjewett at gmail.com
Thu Dec 18 21:36:07 CET 2014



On Thu, Dec 18, 2014, at 14:13, Maciej Fijalkowski wrote:
> ... http://bugs.python.org/issue23085 ...
> is there any reason any more for libffi being included in CPython?

[And why a fork, instead of just treating it as an external dependency]

Benjamin Peterson responded:

> It has some sort of Windows related patches. No one seems to know
> whether they're still needed for newer libffi. Unfortunately, ctypes
> doesn't currently have a maintainer.

Are any of the following false?

(1)  Ideally, we would treat it as an external dependency.

(2)  At one point, it was intentionally forked to get in needed
patches, including at least some for 64 bit windows with MSVC.

(3)  Upstream libffi maintenance has picked back up.

(4)  Alas, that means the switch merge would not be trivial.

(5)  In theory, we could now switch to the external version.
[In particular, does libffi have a release policy such that we
could assume the newest released version is "safe", so long as
our integration doesn't break?]

(6)  By its very nature, libffi changes are risky and undertested.
At the moment, that is also true of its primary user, ctypes.

(7)  So a switch is OK in theory, but someone has to do the
non-trivial testing and merging, and agree to support both libffi
and and ctypes in the future.  Otherwise, stable wins.

(8)  The need for future support makes this a bad candidate for
"patches wanted"/"bug bounty"/GSoC.

-jJ

--

If there are still threading problems with my replies, please
email me with details, so that I can try to resolve them.  -jJ


More information about the Python-Dev mailing list