我使用Ubuntu，并安装了Python 2.7.5和3.4.0。在Python 2.7.5中，我能够成功地分配一个变量x = Value(' I '， 2)，但在3.4.0中不能。我得到:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python3.4/multiprocessing/context.py", line 132, in Value
from .sharedctypes import Value
File "/usr/local/lib/python3.4/multiprocessing/sharedctypes.py", line 10, in <
module>
import ctypes
File "/usr/local/lib/python3.4/ctypes/__init__.py", line 7, in <module>
from _ctypes import Union, Structure, Array
ImportError: No module named '_ctypes'
我刚刚通过安装3.4.0的源代码更新到了3.3.2。它安装在/usr/local/lib/python3.4.
我是否正确地更新到Python 3.4 ?
我注意到一件事，Python 3.4安装在usr/local/lib中，而Python 3.3.2仍然安装在usr/lib中，所以它没有被覆盖。
在我的Ubuntu 18.04机器上，我有一个常见的问题，python找不到_ctypes与pyenv安装的python。
在我的例子中，libffi-dev已经安装了。按照@MikeiLL的建议，从源代码安装cpython也没有帮助。
结果发现是自制的问题。
Ajkerrigans建议解决方案的pyenvs github问题为我解决了这个问题。
解决方案总结:告诉pyenv使用homebrew管理的GCC构建Python，使用如下命令:
CC="$(brew --prefix gcc)/bin/gcc-11" \
pyenv install --verbose 3.10.0
这假设任何构建依赖项都已通过pyenv wiki中指定的Homebrew安装。在写这篇文章时，Linux上的Homebrew看起来是这样的:
brew install bzip2 libffi libxml2 libxmlsec1 openssl readline sqlite xz zlib
在一个新的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并按常规方式将其安装到用户安装区。
git clone https://github.com/libffi/libffi.git
cd libffi
./configure --prefix=path/to/your/install/root
make
make install
然后回到你的Python 3源代码，在Python源代码目录的顶层的setup.py中找到这部分代码
ffi_inc = [sysconfig.get_config_var("LIBFFI_INCLUDEDIR")]
if not ffi_inc or ffi_inc[0] == '':
ffi_inc = find_file('ffi.h', [], inc_dirs)
if ffi_inc is not None:
ffi_h = ffi_inc[0] + '/ffi.h'
if not os.path.exists(ffi_h):
ffi_inc = None
print('Header file {} does not exist'.format(ffi_h))
ffi_lib = None
if ffi_inc is not None:
for lib_name in ('ffi', 'ffi_pic'):
if (self.compiler.find_library_file(lib_dirs, lib_name)):
ffi_lib = lib_name
break
ffi_lib="ffi" # --- AND INSERT THIS LINE HERE THAT DOES NOT APPEAR ---
if ffi_inc and ffi_lib:
ext.include_dirs.extend(ffi_inc)
ext.libraries.append(ffi_lib)
self.use_system_libffi = True
并添加我上面标记的注释行。为什么它是必要的，以及为什么没有办法在Linux平台上配置尊重“——without-system-ffi”，也许我会在接下来的几个小时里找到为什么它“不受支持”，但从那以后一切都正常工作。否则，祝你好运……YMMV。
它做什么:只是覆盖那里的逻辑，并导致编译器链接命令添加“-lffi”，这是它真正需要的。如果你的库是用户安装的，那么只要你的PKG_CONFIG_PATH包含路径/到/your/install/root/lib/pkgconfig，它就可以很好地检测到头文件。
在我的Ubuntu 18.04机器上，我有一个常见的问题，python找不到_ctypes与pyenv安装的python。
在我的例子中，libffi-dev已经安装了。按照@MikeiLL的建议，从源代码安装cpython也没有帮助。
结果发现是自制的问题。
Ajkerrigans建议解决方案的pyenvs github问题为我解决了这个问题。
解决方案总结:告诉pyenv使用homebrew管理的GCC构建Python，使用如下命令:
CC="$(brew --prefix gcc)/bin/gcc-11" \
pyenv install --verbose 3.10.0
这假设任何构建依赖项都已通过pyenv wiki中指定的Homebrew安装。在写这篇文章时，Linux上的Homebrew看起来是这样的:
brew install bzip2 libffi libxml2 libxmlsec1 openssl readline sqlite xz zlib
