gperftools在aarch64架构下的编译问题分析与解决

问题背景

在aarch64架构的CentOS 7.6系统上编译gperftools 2.15版本时，遇到了链接单元测试时的错误。错误信息显示链接器在处理pthread_atfork符号时出现问题，提示"hidden symbol is referenced by DSO"。这个问题在x86-64架构的相同系统上并未出现。

技术分析

符号可见性问题

错误的核心在于链接器发现了一个隐藏符号pthread_atfork被动态共享对象(DSO)引用。在Linux系统中，符号的可见性控制是动态链接过程中的一个重要机制。

通过对比aarch64和x86-64架构下的libpthread.so库，我们发现：

1. 在aarch64架构下：

   • pthread_atfork符号被标记为隐藏(.hidden)
   • 该符号位于libpthread_nonshared.a静态库中
   • 动态库libpthread.so.0中没有直接导出这个符号

2. 在x86-64架构下：

   • pthread_atfork符号正常导出(有@GLIBC_2.2.5版本标记)
   • 符号同时存在于动态库和静态库中

架构差异的根本原因

这种差异源于不同架构下glibc的实现方式。aarch64版本似乎将pthread_atfork实现放在了非共享的静态库部分，并且标记为隐藏符号，这可能是出于性能或ABI稳定性的考虑。

解决方案

gperftools项目团队已经在新版本(master分支)中解决了这个问题。解决方案可能包括：

1. 修改构建系统配置，正确处理不同架构下的符号可见性
2. 调整单元测试的链接方式，避免直接依赖隐藏符号
3. 更新automake规则，更好地处理跨平台兼容性问题

建议

对于遇到类似问题的用户：

1. 建议升级到最新版本的gperftools，因为问题已在master分支修复
2. 如果必须使用2.15版本，可以尝试以下临时解决方案：
   • 在链接时添加适当的符号可见性控制标志
   • 修改构建配置，明确指定pthread库的链接方式

总结

跨平台开发中，不同架构下的库实现细节差异可能导致意料之外的构建问题。gperftools的这个案例展示了符号可见性控制在多架构支持中的重要性。随着项目的发展，构建系统的不断完善能够更好地处理这些平台差异性问题。