深入理解 CFFI 动态链接：解决 C 级别符号依赖的策略与实践

cffi的`ffi.include()`方法主要用于python层面的ffi对象间类型和声明共享，而非解决c语言层面的编译时符号依赖。当cffi模块在编译时需要引用其他模块的c函数符号时，直接使用`include()`会导致链接错误。本文将深入探讨这一常见误解，并提供多种有效的解决方案，包括整合ffi实例、构建标准c库、以及通过运行时赋值解除c层依赖，确保cffi项目能够正确处理复杂的c库依赖关系。

在使用 CFFI（C Foreign Function Interface）与 C 语言库进行交互时，开发者常会遇到如何处理 C 库间依赖的问题，尤其是在尝试将多个 CFFI 模块动态链接在一起时。一个常见的误解是，ffibuilder.include(other_ffibuilder) 能够解决 C 语言层面的编译时符号依赖。然而，实际情况并非如此，这往往导致在导入 CFFI 生成的共享库时出现“未定义符号”错误。

理解 CFFI 的 include() 机制

CFFI 的 ffibuilder.include(other_ffibuilder) 机制主要用于在 Python 层面共享 FFI 对象间的类型定义和函数声明。这意味着，如果 ffi_b 包含了 ffi_a，那么 ffi_b 的 FFI 对象将能够访问 ffi_a 中定义的类型（如 struct）和函数签名。同时，在 Python 运行时，ffi_b.lib 也能通过内部机制访问 ffi_a.lib 中的 C 函数。

然而，这种包含关系并不会影响 C 语言代码的编译过程。当 ffi_b.set_source() 编译 foo_b.c 文件以生成 _ffi_foo_b.so（或 .pyd）时，如果 foo_b.c 直接调用了 foo_a.c 中定义的函数（例如 bar），C 编译器和链接器在构建 _ffi_foo_b.so 时，并不知道 bar 的定义存在于另一个未来会加载的共享库 _ffi_foo_a.so 中。因此，它会报告 bar 为未定义符号，导致编译失败或运行时导入错误。

特别是在 Windows 平台上，共享库（DLL 或 PYD）默认不导出其所有符号，除非显式标记。这意味着即使 _ffi_foo_a.so 包含了 bar 函数，它也可能不会将其导出为可供其他 C 模块链接的符号，进一步加剧了 C 级别符号依赖的问题。

解决 C 级别符号依赖的策略

鉴于 ffi.include() 的局限性，处理 CFFI 模块间 C 级别符号依赖需要采用更明确的策略。以下是几种推荐的解决方案：

1. 整合所有 C 代码到一个单一 FFI 实例

最直接的方法是将所有相关的 C 源代码和声明都集中到一个 FFI 实例中进行编译。这样可以避免跨 CFFI 模块的 C 级别链接问题，因为所有符号都在同一个编译单元中。

from cffi import FFI
from pathlib import Path

# ... (foo_a.h, foo_a.c, foo_b.h, foo_b.c 的文件创建代码不变) ...

ffi = FFI()
ffi.cdef("""
int bar(int x);
int baz(int x);
""")
# 将所有 C 源文件合并到 set_source
ffi.set_source('ffi_combined',
               '#include "foo_a.h"\n#include "foo_b.h"',
               sources=['foo_a.c', 'foo_b.c'])
ffi.compile()

import ffi_combined
if ffi_combined.lib.bar(1) == 70: print('foo_a OK (combined)')
else: raise AssertionError('foo_a ERR (combined)')

if ffi_combined.lib.baz(420) == 42069: print('foo_b OK (combined)')
else: raise AssertionError('foo_b ERR (combined)')

优点： 简单直接，避免了复杂的 C 级别链接问题。 缺点： 适用于项目规模较小或模块间耦合度高的情况。如果 C 库非常庞大或需要独立维护，这种方法可能不够灵活。

2. 构建标准的 C 共享库并使用 CFFI 封装

这是一种更符合 C 语言生态系统的方式。首先，使用标准的 C 工具链（如 GCC 或 Clang）将 C 源文件编译成独立的共享库（.so 或 .dll），并确保它们之间正确链接。然后，CFFI 只负责加载这些预编译的共享库并提供 Python 接口。

步骤：

1. 编译 foo_a.c 为 foo_a.so：

   gcc -shared -o foo_a.so foo_a.c

   登录后复制

2. 编译 foo_b.c 为 foo_b.so，并链接 foo_a.so：

   gcc -shared -o foo_b.so foo_b.c -L. -lfoo_a

   登录后复制

   这里的 -L. 告诉链接器在当前目录查找库，-lfoo_a 指示链接 libfoo_a.so。

3. 使用 CFFI 封装：

   

   千面视频动捕

   千面视频动捕是一个AI视频动捕解决方案，专注于将视频中的人体关节二维信息转化为三维模型动作。

   27

   查看详情

   from cffi import FFI
   from pathlib import Path
   
   # ... (foo_a.h, foo_a.c, foo_b.h, foo_b.c 的文件创建代码不变) ...
   
   # 编译 C 库（此处假设已通过上述 shell 命令完成）
   
   ffi_a = FFI()
   ffi_a.cdef('int bar(int x);')
   # 直接加载预编译的 foo_a.so
   lib_a = ffi_a.dlopen('./foo_a.so')
   
   ffi_b = FFI()
   ffi_b.cdef('int baz(int x);')
   # 直接加载预编译的 foo_b.so
   lib_b = ffi_b.dlopen('./foo_b.so')
   
   # 现在可以在 Python 中通过 lib_b 调用 baz，它会正确调用 lib_a 中的 bar
   if lib_a.bar(1) == 70: print('foo_a OK (standalone)')
   else: raise AssertionError('foo_a ERR (standalone)')
   
   if lib_b.baz(420) == 42069: print('foo_b OK (standalone)')
   else: raise AssertionError('foo_b ERR (standalone)')

   登录后复制

   注意： 在这种情况下，ffi.include() 仍然可以用于共享 FFI 声明，例如：

   ffi_b.include(ffi_a) # 仅用于共享声明，不影响 C 级别链接
   # ffi_b.cdef('int bar(int x);') # 如果 ffi_a 已经定义了 bar，则 ffi_b 也可以访问

   登录后复制

优点： 遵循 C 语言模块化开发的最佳实践，适用于大型、复杂的 C 库项目。 缺点： 需要额外的构建步骤和工具链知识。

3. 混合方法：独立 C 库与 CFFI 模块结合

你可以将依赖的 C 库（如 foo_a）编译成独立的共享库，然后用一个 CFFI 实例（ffi_a）来封装它。而对于依赖于它的 CFFI 模块（ffi_b），如果它没有被其他 C 模块依赖，则可以继续使用 set_source() 方式构建。

这种方法本质上是方案 2 的变体，但更强调了 CFFI 模块的独立性。如果 ffi_b 的 C 代码需要 foo_a 中的符号，那么 ffi_b 的 set_source 仍然需要链接到 foo_a.so。

4. 运行时符号赋值（推荐）

这是一个非常灵活且强大的解决方案，它通过在 Python 运行时动态地将一个 C 函数指针赋值给另一个 CFFI 模块中的全局函数指针，从而完全绕过 C 级别的编译时链接问题。

实现步骤：

1. 修改 foo_b.c： 不再直接调用 bar()，而是声明一个全局函数指针 _glob_bar，并通过它来调用函数。

   // foo_b.c
   #include "foo_b.h"
   static int (*_glob_bar)(int); // 声明一个全局函数指针
   int baz(int x) {
     return _glob_bar(x * 100); // 通过函数指针调用
   }

   登录后复制

2. 修改 ffi_b.cdef： 声明这个全局函数指针。

   # ffi_b.cdef
   ffi_b.cdef("""
       int (*_glob_bar)(int); // 声明全局函数指针
       int baz(int x);
   """)

   登录后复制

3. 在 Python 运行时赋值： 在导入两个 CFFI 模块后，将 ffi_foo_a.lib.bar 的地址赋值给 ffi_foo_b.lib._glob_bar。

   from cffi import FFI
   from pathlib import Path
   
   # ... (foo_a.h, foo_a.c, foo_b.h, foo_b.c 的文件创建代码不变) ...
   
   # 创建并编译 ffi_a
   ffi_a = 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_b (使用修改后的 foo_b.c 和 cdef)
   Path('foo_b.c').write_text("""\
   #include "foo_b.h"
   static int (*_glob_bar)(int); // 全局函数指针
   int baz(int x) {
     return _glob_bar(x * 100);
   }
   """)
   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()
   
   # 导入并进行运行时赋值
   import ffi_foo_a
   import ffi_foo_b
   
   # 验证 ffi_foo_a
   if ffi_foo_a.lib.bar(1) == 70: print('foo_a OK')
   else: raise AssertionError('foo_a ERR')
   
   # 将 ffi_foo_a.lib.bar 的地址赋值给 ffi_foo_b.lib._glob_bar
   ffi_foo_b.lib._glob_bar = ffi_foo_a.ffi.addressof(ffi_foo_a.lib, "bar")
   
   # 现在可以调用 ffi_foo_b.lib.baz
   if ffi_foo_b.lib.baz(420) == 42069: print('foo_b OK')
   else: raise AssertionError('foo_b ERR')

   登录后复制

优点： 极大增强了灵活性，将 C 级别的编译时依赖转换为 Python 级别的运行时配置，避免了复杂的链接器指令。 缺点： 需要修改 C 源代码，并引入一个全局函数指针，可能略微增加了 C 代码的复杂性。

5. 平台和编译器特定选项（不推荐）

理论上，可以通过添加平台和编译器特定的选项（例如，在 GCC 中使用 -fPIC 和 -rdynamic，或在 Windows 中使用 __declspec(dllexport)）来确保符号被正确导出和链接。然而，这种方法往往导致代码可移植性差，且配置复杂，通常不推荐作为首选方案。

总结与注意事项

处理 CFFI 中 C 级别库依赖的核心在于理解 ffi.include() 的作用范围仅限于 Python 层面 FFI 对象的声明共享，而非 C 编译时的链接。当 C 代码需要引用其他 CFFI 模块中的 C 函数时，必须确保这些符号在 C 编译和链接阶段是可解析的。

• 对于简单项目，整合单一 FFI 实例是最直接的方案。
• 对于复杂的、需要独立维护的 C 库，构建标准的 C 共享库并用 CFFI 封装是最佳实践。
• 运行时符号赋值提供了一种巧妙且灵活的方式，通过 Python 动态配置来解除 C 级别的编译时依赖，特别适用于避免修改构建系统或需要更细粒度控制的场景。

选择哪种方案取决于项目的具体需求、C 库的复杂性以及对构建流程的控制程度。通过正确理解和应用这些策略，可以有效地管理 CFFI 项目中的 C 语言库依赖。

以上就是深入理解 CFFI 动态链接：解决 C 级别符号依赖的策略与实践的详细内容，更多请关注php中文网其它相关文章！