交叉编译的Python无法找到基本模块（math，operator等）
我似乎无法导入位于“lib-dynload”目录下的任何基本模块。它们都在那儿，但我在尝试导入时却遇到了错误："ImportError: No module named X"。
我检查了我的sys.path，发现它包含了所有这些模块所在的目录，而且我的PYTHONHOME环境变量设置也正确。我有点搞不清楚问题出在哪里。一些背景信息：这是从Python 2.6.6源代码交叉编译的，并安装在一个使用Angstrom的ARM嵌入式Linux板上。
之前那里确实有python，我尝试将它打包到镜像中，但缺少很多东西。最后我尽力清理了与之前的python相关的目录，然后才加载我交叉编译的版本。
这是一个简单脚本的strace，它只是尝试导入math模块：http://pastebin.com/3XgJ3nPR
2 个回答
我最近在构建 Python 2.7.13 的时候遇到了类似的问题，我认为这是一个正在修复的 bug，这个问题在 Python 3 中已经解决，但没有回到 Python 2 上。构建过程（setup.py）会生成一个要构建的模块列表，然后再减去内置模块的列表（sys.builtin_module_names）；不过，setup.py 是通过 Makefile 运行的，使用的是 python2.7，在我的情况下，它使用了系统（Ubuntu）自带的 Python，而不是我自己构建的那个，所以它减去了系统 Python 中的内置模块（包括 operator 和 collections），而这些模块在我构建的 Python 中既不是内置的，也没有作为外部模块构建。
我根据这个 bug 的建议，先把我构建的 Python 加到路径中（在源代码目录下），并创建了一个从 python2.7 指向 python 的符号链接。这是有效的，因为我是在一个多架构的 x64 机器上构建 x86 的 Python；如果你是在为其他系统，比如 ARM，构建，你可能需要应用这个 bug 的补丁，以便在构建过程中更早地获取内置模块的列表，而不是使用主机的 Python。
我在这个追踪记录中没有看到像 math.so 或 mathmodule.so 这样的文件名检查，这可能意味着共享对象模块完全被关闭了——也就是说，你编译的这个Python版本无法动态加载二进制模块。
更多信息：在我最近一次编译Python时查看 config.out 文件，我看到有几行在检查这个平台是否允许它动态加载以 .so 结尾的二进制模块：
checking for dlopen... yes
checking DYNLOADFILE... dynload_shlib.o
checking MACHDEP_OBJS... MACHDEP_OBJS
在你的交叉编译中，这些行显示了什么？