调用std::pow需GLIBC2.29，Ubuntu编译程序在RHEL8运行报错如何解决？

我在Ubuntu 20.04环境下编译程序，此前该程序可在RedHat 8正常运行，但引入<cmath>头文件并使用std::pow(double, double)后，在RedHat 8上出现如下错误：

/lib64/libm.so.6: version `GLIBC_2.29' not found (required by /MyOwnLib.so)

为什么std::pow会要求GLIBC_2.29？ #

• 别被std::pow的"老旧"属性误导，GLIBC会对已有函数的符号版本进行升级，2.29版本确实更新了pow(double, double)的符号绑定规则。
• Ubuntu 20.04默认使用的gcc版本较高，编译时会默认链接GLIBC 2.29引入的pow新符号版本——哪怕函数功能逻辑没变化，符号版本号提升就会触发依赖要求。
• RedHat 8默认搭载的GLIBC版本是2.28，低于2.29，运行时无法找到对应版本的符号，因此报错。

能否让Ubuntu编译器链接旧版本GLIBC？ #

直接让Ubuntu的gcc链接旧版本GLIBC不可行，因为编译器与系统GLIBC深度绑定，但可以通过以下几种方法解决兼容问题：

• 静态链接标准库：编译时添加-static-libgcc -static-libstdc++参数，将依赖的C/C++标准库静态打包到你的库或程序中，避免依赖系统动态GLIBC。缺点是会增大程序体积，且部分系统调用仍依赖动态GLIBC。
• 交叉编译：在Ubuntu上安装针对RedHat 8的交叉编译工具链，模拟目标环境的GLIBC版本编译，确保生成的二进制兼容RedHat 8。
• 强制绑定旧符号版本：通过嵌入汇编指令强制编译器使用旧版本符号，比如添加__asm__(".symver pow,pow@GLIBC_2.2.5")，但这种方式需要熟悉GLIBC符号版本规则，存在一定兼容性风险。
• 容器内编译：使用RedHat 8的容器镜像（如Docker/Podman拉取RHEL8镜像），在容器环境内完成编译，生成的二进制天然兼容RedHat 8的GLIBC版本，这是最稳妥的方案。

内容的提问来源于stack exchange，提问作者D.R.