This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: libffi detection doesn’t work in my setup
Type: compile error Stage: resolved
Components: Installation Versions: Python 3.7
Status: closed Resolution: duplicate
Dependencies: Superseder: How to link with a non-system libffi?
View: 14527
Assigned To: Nosy List: fetchinson, ned.deily, stapelberg
Priority: normal Keywords:

Created on 2018-09-27 16:58 by stapelberg, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Messages (5)
msg326572 - (view) Author: Michael Stapelberg (stapelberg) Date: 2018-09-27 16:58
(Tested with Python 3.7, but AFAICT, the situation hasn’t changed in Python 3.8.)

Python’s configure tries to fill the LIBFFI_INCLUDEDIR system variable with the value of -I as returned by pkg-config libffi --cflags-only-I.

Python’s tries to determine whether libffi is present by searching a couple of well-known library directories.

Both of these checks fail in my environment (think Linux From Scratch). I’m setting the following environment variables:


gcc can build against libffi just fine:

% echo echo '#include <ffi.h>                  
> int main() {}' > foo.c
% gcc -o foo foo.c -lffi
% ldd foo (0x00007ffe4450a000) => /home/michael/libffi-3.2.1/lib64/ (0x00007f3935aba000) => /home/michael/glibc-2.27/lib/ (0x00007f3935902000)
	/lib64/ => /home/michael/glibc-2.27/lib/ (0x00007f3935aca000)

However, when compiling Python, I’m getting the following error message, resulting in the _ctypes module not being built:

INFO: Could not locate ffi libs and/or headers

Now, one issue is that pkg-config understands CPATH, so calling pkg-config --cflags-only-I is not sufficient to obtain the include directory, one also needs to clear CPATH:

% pkg-config libffi --cflags-only-I      

% CPATH= pkg-config libffi --cflags-only-I

After patching this in configure, LIBFFI_INCLUDEDIR is set correctly, but the build still fails, as the libffi shared object is located in my non-standard path, which doesn’t check.

Without knowing much about the Python internals, it seems to me that both of these issues would be fixed if Python stopped trying to find the libffi include/lib locations and just used pkg-config to detect the required CFLAGS and LDFLAGS, just like Python currently does with openssl.

Is there any reason we can’t use pkg-config for libffi like that?

msg332297 - (view) Author: Daniel Fetchinson (fetchinson) Date: 2018-12-21 20:36
I have the exact same issue, trying to compile 3.7.1 with a custom libffi location. Note that I must build libffi from source and can't install binaries provided by my distro, I believe this is the origin of the problem. Probably the python build system checks for libffi in some "standard" locations and it doesn't seem possible to use libffi from a custom location.

This is where libffi gets installed after passing --prefix=$HOME/opt to ./configure:


In any case, just to be sure, I've copied the header files to


And pkg-config works:

[fetch@fetch opt]$ pkg-config --libs libffi
-L/home/fetch/opt/lib/../lib64 -lffi

[fetch@fetch opt]$ pkg-config --cflags libffi

These environment variables are also set:



And still _ctypes fails to build (but python itself (minus _ctypes) compiles successful and works perfectly well).
msg332298 - (view) Author: Daniel Fetchinson (fetchinson) Date: 2018-12-21 20:37
It would be really great if this could be sorted out because at the moment this bug prevents me from using numpy/scipy with python 3.7.1 (they need _ctypes).
msg332509 - (view) Author: Daniel Fetchinson (fetchinson) Date: 2018-12-25 13:16
It seems there is a way to fix this:

LDFLAGS=`pkg-config --libs-only-L libffi` ./configure

Would be nice to document this or make the build system find the libraries and headers in a simpler way.
msg368415 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2020-05-08 03:22
Thanks for the report and for the analysis. There have been a number of reports over the years about problems trying to build and/or execute Pythons with an external copy of libffi. They have become more pressing now that we no longer vendor the source of libffi in Python source releases. To help focus on the issues, we are consolidated the discussion in Issue14527, one of the earliest opened issues.
Date User Action Args
2022-04-11 14:59:06adminsetgithub: 79004
2020-05-08 03:22:08ned.deilysetstatus: open -> closed

superseder: How to link with a non-system libffi?

nosy: + ned.deily
messages: + msg368415
resolution: duplicate
stage: resolved
2018-12-25 13:16:49fetchinsonsetmessages: + msg332509
2018-12-21 20:37:49fetchinsonsetmessages: + msg332298
2018-12-21 20:36:15fetchinsonsetnosy: + fetchinson
messages: + msg332297
2018-09-27 16:58:23stapelbergcreate