ONNXRuntime 构建问题：静态库依赖与共享库构建方案分析

在 ONNXRuntime 项目的构建过程中，开发者可能会遇到一个典型的依赖管理问题：当尝试使用已安装的 ONNXRuntime 包时，发现缺少来自 protobuf、onnx 和 absl 等命名空间的符号定义。这些符号实际上只存在于构建目录中的静态库文件（如 libprotobuf.a）中，导致安装后的包无法正常使用。

问题本质分析

这个问题的核心在于 ONNXRuntime 的默认构建配置会生成静态库，但不会将这些第三方依赖的符号打包到最终的安装包中。当用户尝试使用安装后的 ONNXRuntime 时，特别是在调用某些需要这些依赖符号的接口时（如 onnxruntime::Initializer 的构造函数），就会出现链接错误。

解决方案

经过项目维护者的确认，目前推荐的解决方案是通过构建共享库（shared library）来解决这个问题。具体方法是在构建时添加 --build_shared_lib 参数：

1. 使用构建脚本时添加参数：

python tools/ci_build/build.py --build_shared_lib

2. 直接使用 CMake 时：

cmake -DONNX_BUILD_SHARED_LIBS=ON .
make
make install

技术背景

静态库与共享库在依赖管理上有显著差异：

1. 静态库：会将所有代码直接嵌入最终的可执行文件，但不会自动包含依赖的第三方库
2. 共享库：会在运行时动态加载，可以更好地管理依赖关系，特别是对于大型项目

ONNXRuntime 作为一个机器学习推理引擎，依赖了多个重量级库（如 Protobuf、ONNX 等），使用共享库方式可以更好地管理这些依赖关系。

未来发展方向

项目维护者表示，虽然目前不支持静态库分发方案（因为需要考虑编译器版本和编译标志的一致性），但未来可能会通过 vcpkg 来提供更好的静态库支持。vcpkg 能够帮助检查编译器版本并提供隔离环境，确保构建的可重复性。

实践建议

对于希望在 FreeBSD 等系统上使用 ONNXRuntime 的开发者：

1. 优先考虑使用共享库构建方式
2. 确保系统已安装所有必要的依赖项
3. 在构建完成后，使用 make install 正确安装库文件和头文件
4. 在自己的项目中使用 CMake 的 find_package 来定位已安装的 ONNXRuntime

通过这种方式，可以确保 ONNXRuntime 及其所有依赖都能被正确链接和使用，避免出现符号缺失的问题。