[Python-Dev] libffi inclusion in python
ronaldoussoren at mac.com
Thu Apr 18 23:17:38 CEST 2013
On 18 apr. 2013, at 18:09, Ned Deily <nad at acm.org> wrote:
> 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?
It is probably just a matter of supporting universal builds, but I haven't checked the state of upstream libffi in the last couple of years.
The libffi_osx tree is a fork from upstream that started around the time of OSX 10.4, and possibly earlier. As Thomas mentioned the upstream maintainer weren't very responsive in the past, at the time I hacked on libffi (IIRC for Darwin/i386 support) it wasn't even clear how the maintainers could be reached.
Stripping libffi from python's source tree would be fine by me, but would require testing with upstream libffi. AFAIK system libffi on osx wouldn't be goog enough, it doesn't work properly with clang.
> 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
> Python-Dev mailing list
> Python-Dev at python.org
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com
More information about the Python-Dev