[Python-Dev] libffi embedded in CPython

Thomas Wouters thomas at python.org
Thu Mar 12 20:58:32 CET 2015


On Thu, Mar 12, 2015 at 6:26 PM, Brett Cannon <brett at python.org> wrote:
>
>
> For UNIX OSs we could probably rely on the system libffi then.
>

Yes, it's possible to use the system libffi -- that's what most linux
distros already do -- but only if you use dynamic linking. If you want to
statically link libffi (useful when embedding, making installations that
are a little more portable across systems, or when you're a company like
Google that wants to statically link all the things) it's a little more
confusing. (The reason Brett started this thread is that I mentioned these
issues in an internal Google meeting that he happened to be in ;-P)

_ctypes currently contains a bunch of duplicate definitions of the
ffi_type_* structs (in Modules/_ctypes/cfield.c.) It also contains a
separate implementation of ffi_closure_alloc and ffi_closure_free (in
Modules/_ctypes/malloc_closure.c) which is only used on OSX. I guess those
redefinitions are to cope with (much) older libffis, but that's just a
guess. The redefinitions aren't a problem when using dynamic linking, as
long as the new definitions aren't incompatible, but if libffi were to
change the ABI of the ffi_type structs, yuck. It can be a problem when
statically linking, depending on how you link -- and the only reason it
works with the bundled libffi is that ctypes *does not build libffi the
normal way*. Instead it runs libffi's configure and then selectively builds
a few source files from it, using distutils.

It would be a really, really good idea to clean up that mess if we're not
going to bundle libffi anymore :-P

Screaming-and-stabbing-at-setup.py'ly y'rs,
-- 
Thomas Wouters <thomas at python.org>

Hi! I'm an email virus! Think twice before sending your email to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150312/bff0d257/attachment.html>


More information about the Python-Dev mailing list