We ran into the same issue in conda-forge ( https://github.com/conda-forge/python-feedstock/issues/522 ).

The problem is Apple also supplies their own `libffi`. However if the build scripts in CPython fail to find the user provided `libffi`, they end up pulling the headers from Apple's `libffi`, but the linker will link to the user provided `libffi`. IOW mashing these two incompatible `libffi`'s together. As result one gets crashes like the one illustrated in this bug.

In conda-forge, we are resolving this by forcing our `pkg-config` to be used to ensure we pick up the headers from our `libffi` as well as the libraries. Other users may be able to workaround this issue by explicitly setting `LIBFFI_INCLUDE_DIR`.

That said, it would be preferable to have a clear way to specify the `libffi` used and ensure that Apple's one doesn't get accidentally pulled in. If this exists and we are just missing these details, some pointers to this effect would be very helpful.