从NASM调用PyImport_Import导入NLTK/Numpy报错但C调用正常如何解决

核心原因是Python核心C API符号的全局可见性不足，具体差异来源如下：

• 你编译C可执行文件时，链接器默认会将依赖的libpython库中的全局符号（如PyTuple_Type、PyExc_RecursionError）导出到进程全局符号表，NLTK、Numpy依赖的第三方C扩展（如regex的_regex.cpython-38-x86_64-linux-gnu.so、numpy的核心扩展库）加载时可以正常找到这些符号。
• 你的NASM编译产物是共享对象，触发符号不可见的常见场景有两个：
  • 链接共享对象时未显式链接libpython库，也未开启全局符号导出配置
  • 加载该共享对象时使用了RTLD_LOCAL模式（dlopen的默认参数），导致共享对象依赖的libpython符号仅在该共享对象的局部符号表中可见，后续加载的Python第三方C扩展无法访问
• Python内置math库不需要额外加载独立的C扩展，符号可以直接从Python解释器实例获取，因此不会触发该错误。

执行以下命令确认符号导出状态，将路径替换为你自己的二进制文件路径：

1. 查看C可执行文件的符号导出：nm -D 你的C可执行文件路径 | grep PyTuple_Type，正常可以看到已导出的该符号
2. 查看NASM共享对象的符号导出：nm -D 你的NASM共享对象路径 | grep PyTuple_Type，如果未找到该符号或者状态为未解析，即可确认是符号可见性问题

根据你的使用场景任选一种即可：

• 方案1：调整共享对象链接参数
  链接NASM编译生成的.o文件为共享对象时，添加libpython链接和全局符号导出参数，以Python3.8为例，添加-lpython3.8 -rdynamic到链接参数中
• 方案2：调整共享对象加载参数
  如果你是通过dlopen加载该NASM共享对象，将dlopen的参数修改为RTLD_NOW | RTLD_GLOBAL，强制将该共享对象的所有符号导出到进程全局符号表
• 方案3：在C代码中手动加载libpython符号
  在Lib_Gutenberg函数的Py_Initialize()调用前，添加如下代码手动将libpython的符号加载到全局表：

  #include <dlfcn.h>
  // 注意替换为你对应版本的libpython.so路径
  dlopen("libpython3.8.so", RTLD_NOW | RTLD_GLOBAL);
  

内容的提问来源于stack exchange，提问作者RTC222