OpenBLAS项目中使用flang-new编译器遇到的符号链接问题分析

问题背景

在科学计算和高性能计算领域，OpenBLAS作为一个优化的BLAS实现被广泛应用。近期有开发者在尝试使用LLVM的flang-new编译器（版本19.1.1和20.1.0-rc1）编译OpenBLAS 0.3.27和0.3.29版本时，发现编译后的动态链接库中出现了一些未定义的Fortran运行时符号。

现象描述

编译完成后，使用nm工具检查libopenblas.so时，可以观察到以下未解析的符号：

_FortranAAssign
_FortranACharacterCompareScalar1
_FortranAcpowi
_FortranAExponent4_4
_FortranAExponent8_4
_FortranAzpowi

这些符号属于flang的运行时库，但在正常情况下不应该出现在OpenBLAS的导出符号表中。这一问题在后续使用该库（如被numpy通过FlexiBLAS加载）时会导致运行时错误，特别是当动态加载时未使用RTLD_LAZY标志的情况下。

问题根源分析

经过深入调查，发现问题源于构建系统的差异：

1. 当使用传统的gmake构建系统时，OpenBLAS的构建规则没有正确处理flang-new编译器的情况，导致Fortran运行时库没有被正确链接。

2. 相比之下，使用CMake构建系统时，Fortran运行时库会被正确链接，不会出现这些未定义的符号。

3. 检查发现，这些符号确实存在于libFortranRuntime.a静态库中，但在gmake构建过程中没有被正确包含。

解决方案

OpenBLAS项目维护者迅速响应，通过PR #5138修复了这一问题。修复的核心内容是：

1. 修改构建系统规则，确保在使用flang-new编译器时也能正确处理Fortran运行时库的链接。

2. 更新构建逻辑，使得无论是传统的flang还是新的flang-new编译器，都能获得一致的构建结果。

修复后，这些Fortran运行时符号会被正确包含在生成的动态库中，不再作为未定义符号出现。

技术启示

1. 编译器工具链的兼容性是一个复杂问题，特别是当使用较新的编译器（如flang-new）构建成熟项目时。

2. 构建系统的选择（gmake vs CMake）可能导致不同的构建结果，这在跨平台开发中需要特别注意。

3. 静态库和动态库的符号处理需要谨慎对待，特别是在涉及Fortran和C混合编程的场景中。

4. 对于科学计算软件栈，从底层BLAS实现到上层应用（如numpy）的完整工具链验证非常重要。

最佳实践建议

1. 当使用flang/flang-new编译器构建OpenBLAS时，建议使用最新版本并确认相关补丁已应用。

2. 考虑使用CMake作为构建系统，以获得更一致的构建结果。

3. 在依赖OpenBLAS的上层应用中，确保动态加载库时使用适当的标志（如RTLD_LAZY）以避免类似的运行时问题。

4. 对于完整的科学计算工具链构建，建议进行端到端的测试验证，包括底层库和上层应用的集成测试。

这个问题及其解决方案为使用LLVM工具链构建科学计算软件栈提供了宝贵的经验，也展示了开源社区快速响应和解决问题的能力。