我也有同样的问题。以上的方法对我来说都没用。关键的挑战是我没有根权限。因此，我首先下载libffi的源代码。然后我用常用的命令来编译:

./configure --prefix=desired_installation_path_to_libffi
make 

然后我重新编译python使用

./configure --prefix=/home/user123/Softwares/Python/installation3/  LDFLAGS='-L/home/user123/Softwares/library/libffi/installation/lib64'
make 
make install

在我的例子中，'home/user123/Softwares/library/libffi/installation/lib64'是libffi安装目录的路径。所以是定位。“/home/user123/ software /Python/installation3/ is”为Python安装目录的路径。根据您的情况修改它们。

在一个新的Debian镜像上，克隆https://github.com/python/cpython并运行:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade
sudo apt-get install build-essential python-dev python-setuptools python-pip python-smbus
sudo apt-get install libncursesw5-dev libgdbm-dev libc6-dev
sudo apt-get install zlib1g-dev libsqlite3-dev tk-dev
sudo apt-get install libssl-dev openssl
sudo apt-get install libffi-dev

现在执行上面克隆的配置文件:

./configure
make # alternatively `make -j 4` will utilize 4 threads
sudo make altinstall

安装了3.7，为我工作。

轻微的更新

看起来我说过我会用更多的解释来更新这个答案，两年后我没有什么可补充的了。

这篇SO帖子解释了为什么像python-dev这样的库可能是必要的。 这篇SO帖子解释了为什么在make命令中使用altinstall而不是install参数。

除此之外，我猜选择是阅读cpython代码库，寻找需要满足的#include指令，但我通常做的是继续尝试安装包，并继续阅读输出，安装所需的包，直到成功。

这让我想起了工程师、经理和程序员的故事，他们的汽车滚下了山坡。

参考此线程或此线程，对于libffi的自定义安装，Python3.7很难找到libffi的库位置。另一种方法是在Makefile中设置CONFIGURE_LDFLAGS变量，例如CONFIGURE_LDFLAGS="-L/path/to/libffi-3.2.1/lib64"。

在我的例子中，导致各种Python安装问题(包括与_ctypes和libffi有关的问题)的是Linux / Linuxbrew上的Homebrew。一旦brew不再在$PATH中，pyenv又高兴了。

如何从源代码安装Python没有libffi在/usr/local?

从github下载libffi，安装到/path/to/local 下载python源代码并按以下配置进行编译:

export PKG_CONFIG_PATH=/path/to/local/lib/pkgconfig
./configure --prefix=/path/to/python \
    LDFLAGS='-L/path/to/local/lib -Wl,-R/path/to/local/lib' \
    --enable-optimizations
make
make install

当我试图在Ubuntu 18.04中使用next命令安装Python 3.7.3时，遇到了这个错误:$ pyenv install 3.7.3。 运行$ sudo apt-get update && sudo apt-get install libffi-dev(此处建议)后，安装成功。 问题在那里得到了解决。