本文深入探讨了在 python cffi 中处理 c 库之间动态链接时的常见问题，特别是 `ffi.include()` 在 c 级别符号解析上的局限性。文章通过分析实际案例，揭示了 cffi `include` 方法的真实作用，并提出了多种有效的解决方案，包括合并 ffi 实例、构建标准 c 库、以及通过运行时符号解析来优雅地管理 c 模块间的依赖关系，旨在帮助开发者更准确、高效地使用 cffi。
在使用 Python CFFI（C Foreign Function Interface）进行 C 库的动态链接时，开发者常会遇到一个普遍的困惑：当一个 C 模块（例如 foo_b.c）依赖于另一个 C 模块（例如 foo_a.c）中定义的函数（如 bar）时，简单地通过 ffi_b.include(ffi_a) 并不能在 C 编译层面自动解决符号依赖问题。这导致在导入生成的 Python 扩展模块时，出现“未定义符号”的运行时错误。
考虑以下示例，其中 foo_b 依赖于 foo_a 中定义的 bar 函数：
from cffi import FFI
from pathlib import Path
# 定义 foo_a 库
Path('foo_a.h').write_text("""\
int bar(int x);
""")
Path('foo_a.c').write_text("""\
#include "foo_a.h"
int bar(int x) {
return x + 69;
}
""")
# 定义 foo_b 库，它依赖于 foo_a 的 bar 函数
Path('foo_b.h').write_text("""\
int baz(int x);
""")
Path('foo_b.c').write_text("""\
#include "foo_a.h" # 包含 foo_a 的头文件
#include "foo_b.h"
int baz(int x) {
return bar(x * 100); # 调用 foo_a 中的 bar 函数
}
""")
# CFFI 构建过程
ffi_a = FFI()
ffi_b = FFI()
ffi_a.cdef('int bar(int x);')
ffi_a.set_source('ffi_foo_a', '#include "foo_a.h"', sources=['foo_a.c'])
ffi_a.compile() # 编译生成 ffi_foo_a 模块
ffi_b.cdef('int baz(int x);')
ffi_b.include(ffi_a) # 尝试通过 include 解决依赖
ffi_b.set_source('ffi_foo_b', '#include "foo_b.h"', sources=['foo_b.c'])
ffi_b.compile() # 编译生成 ffi_foo_b 模块
# 导入并测试 ffi_foo_a
import ffi_foo_a
if ffi_foo_a.lib.bar(1) == 70: print('foo_a OK')
else: raise AssertionError('foo_a ERR')
# 导入 ffi_foo_b，此处将发生运行时错误，提示 bar 符号未定义
import ffi_foo_b
if ffi_foo_b.lib.baz(420) == 42069: print('foo_b OK')
else: raise AssertionError('foo_b ERR')上述代码在导入 ffi_foo_b 时会因 bar 符号未定义而崩溃。这表明 ffi_b.include(ffi_a) 语句，虽然在 CFFI 文档中提及，但其作用并非在 C 编译层面为 ffi_foo_b.cpython-XXX.so 提供 ffi_foo_a 中定义的 C 符号。
CFFI 的 ffibuilder.include(other_ffibuilder) 机制主要用于：
它并不能在编译 set_source 指定的 C 源文件时，自动将 other_ffibuilder 对应的 C 库作为链接依赖项。换言之，ffi.include() 不会影响 C 编译器的链接器行为，使其找到 ffi_foo_a 中导出的 C 符号。在许多平台上，CFFI 默认生成的扩展模块并不会自动导出其内部的 C 符号供其他模块直接链接。
为了正确处理 CFFI 模块间的 C 级别符号依赖，可以采用以下几种策略：
最直接的方法是将所有相关的 C 代码合并到一个 FFI 实例中进行编译。这样，所有 C 文件都在同一个编译单元内，C 编译器可以自然地解析所有内部符号。
from cffi import FFI
from pathlib import Path
# ... (foo_a.h, foo_a.c, foo_b.h, foo_b.c 的文件写入部分不变) ...
ffi = FFI() # 只使用一个 FFI 实例
ffi.cdef("""
int bar(int x);
int baz(int x);
""")
# 将所有 C 源文件和头文件包含在一个 set_source 调用中
ffi.set_source(
'ffi_combined',
"""
#include "foo_a.h"
#include "foo_b.h"
""",
sources=['foo_a.c', 'foo_b.c']
)
ffi.compile()
import ffi_combined
if ffi_combined.lib.bar(1) == 70: print('combined bar OK')
else: raise AssertionError('combined bar ERR')
if ffi_combined.lib.baz(420) == 42069: print('combined baz OK')
else: raise AssertionError('combined baz ERR')这种方法简单有效，适用于 C 代码模块化程度不高，或者 CFFI 封装的 C 代码逻辑紧密耦合的场景。
此方案遵循了 C 语言模块化开发的最佳实践：首先将 C 依赖库编译为标准的动态链接库（如 .so 或 .dll），然后让依赖它的 C 库在编译时显式链接这个标准库。最后，CFFI 仅负责封装这些已编译好的标准 C 库。
编译 foo_a 为标准动态库：
# 假设在 Linux/macOS 环境 gcc -shared -fPIC foo_a.c -o libfoo_a.so # 假设在 Windows 环境 # cl /LD foo_a.c /Fe:foo_a.dll
编译 foo_b 并链接 libfoo_a：
# 假设在 Linux/macOS 环境 gcc -shared -fPIC foo_b.c -o libfoo_b.so -L. -lfoo_a # 假设在 Windows 环境 # cl /LD foo_b.c /Fe:foo_b.dll /link foo_a.lib
使用 CFFI 封装：
from cffi import FFI
# 封装 libfoo_a
ffi_a = FFI()
ffi_a.cdef('int bar(int x);')
ffi_a.dlopen('./libfoo_a.so') # 直接加载已编译的动态库
# 封装 libfoo_b
ffi_b = FFI()
ffi_b.cdef('int baz(int x);')
ffi_b.dlopen('./libfoo_b.so') # 直接加载已编译的动态库
# 此时，ffi_b.lib.baz() 可以正常调用，因为 libfoo_b.so 在 C 层面已经链接了 libfoo_a.so
# ffi_b.include(ffi_a) 在此场景下主要用于共享类型定义，而非解决 C 链接问题这种方法是 ffi.include() 最初设计的意图所在，即在 Python 层面共享 FFI 对象，而 C 模块间的实际链接由 C 编译器和链接器完成。
此方案是方案一和方案二的结合。例如，将 foo_a 编译为独立的标准 C 库并用 ffi_a 封装，而 foo_b 仍通过 ffi_b.set_source() 编译。但如果 foo_b.c 内部需要调用 foo_a 中的函数，则 foo_b.set_source() 的编译参数中仍需显式链接 libfoo_a.so。
某些平台和编译器允许通过特定的编译选项来导出 C 符号，例如在 GCC 中使用 __attribute__((visibility("default"))) 或在 Windows 中使用 __declspec(dllexport)。通过 CFFI 的 extra_compile_args 和 extra_link_args 可以尝试添加这些选项。然而，这种方法高度依赖于平台和编译器，会增加代码的复杂性和移植性问题，通常不推荐。
此方案避免了 C 编译层面的直接链接，转而在 Python 运行时，通过 CFFI 将依赖函数的地址手动赋值给一个全局函数指针。这是一种优雅且 CFFI-idiomatic 的解决方案。
修改 foo_b.c： 将对 bar 函数的直接调用替换为通过函数指针的调用。
// foo_b.c
#include "foo_b.h"
static int (*_glob_bar)(int); // 声明一个全局函数指针
int baz(int x) {
return _glob_bar(x * 100); // 通过函数指针调用 bar
}修改 ffi_b.cdef： 在 CFFI 定义中包含这个全局函数指针。
# CFFI 构建脚本
ffi_b = FFI()
ffi_b.cdef("""
int (*_glob_bar)(int); // 声明函数指针
int baz(int x);
""")
ffi_b.set_source('ffi_foo_b', '#include "foo_b.h"', sources=['foo_b.c'])
ffi_b.compile()在 Python 运行时初始化函数指针： 在导入 ffi_foo_b 之后，将 ffi_foo_a.lib.bar 的地址赋值给 ffi_foo_b.lib._glob_bar。
import ffi_foo_a
import ffi_foo_b
# 初始化全局函数指针
ffi_foo_b.lib._glob_bar = ffi_foo_a.ffi.addressof(ffi_foo_a.lib, "bar")
# 现在可以正常调用 baz
if ffi_foo_b.lib.baz(420) == 42069: print('foo_b OK (runtime resolution)')
else: raise AssertionError('foo_b ERR (runtime resolution)')这种方法将 C 模块间的依赖从编译时推迟到运行时，并通过 CFFI 提供的机制进行管理，避免了复杂的 C 链接问题。
CFFI 在 Python 与 C 之间架起了一座桥梁，但理解其工作原理，尤其是在处理 C 模块间动态链接时的行为，对于高效使用至关重要。ffi.include() 主要用于 C 类型定义和 Python 级别 FFI 对象的共享，而非 C 编译器的链接依赖。通过选择合适的策略，无论是合并 C 代码、构建标准 C 库，还是利用 CFFI 的运行时符号解析能力，开发者都能有效地解决 CFFI 动态链接中的符号依赖问题，从而构建出健壮且可维护的 Python 扩展。
以上就是CFFI 动态链接深度解析：解决跨模块 C 符号依赖问题的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
330
收藏
