[Python-Dev] libffi inclusion in python

Ned Deily nad at acm.org
Thu Apr 18 18:09:09 CEST 2013


In article 
<CAPZV6o_HRmkU_=1MZPJDzJGZOBTwBZneV-rjtqBP8P-6tu+AHA at mail.gmail.com>,
 Benjamin Peterson <benjamin at python.org> wrote:
> 2013/4/18 Maciej Fijalkowski <fijall at gmail.com>:
> > libffi has bugs sometimes (like this
> > http://bugs.python.org/issue17580). Now this is a thing that upstream
> > fixes really quickly, but tracking down issues on bugs.python.org is
> > annoying (they never get commited as quickly as the upstream). is
> > there a good reason why cpython has it's own copy of libffi? I
> > understand historical reasons, but PyPy gets along relying on the
> > system library, so maybe we can kill the inclusion.
> 
> IIRC, it had (has?) some custom windows patches, which no one knows
> whether they're relevant or not.

The cpython copy also has custom OS X patches.  I've never looked at 
them so I don't have a feel for how much work would be involved in 
migrating to current upstream.  If it's just a matter of supporting 
universal builds, it could be done with some Makefile hacking to do a 
lipo dance.  Ronald, any additional thoughts?

http://bugs.python.org/issue15194

Currently, for the OS X installer builds, we build a number of 
third-party libs that are either missing from OS X (like lzma) or are 
too out-of-date on the oldest systems we support.  It would be useful to 
generalize the third-party lib support and move it out of the installer 
build process so that all builds could take advantage of the libs if 
needed.  libffi could be added to those.  Of course, that wouldn't help 
for Windows builds.

-- 
 Ned Deily,
 nad at acm.org



More information about the Python-Dev mailing list