On Thu, Mar 12, 2015 at 6:26 PM, Brett Cannon <brett@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@python.org>

Hi! I'm an email virus! Think twice before sending your email to help me spread!