如何构建可在libc>=2.31的Linux系统运行的C++应用

1. 你的判断完全正确 #

glibc采用向后兼容的符号版本控制机制，程序动态依赖的所有符号对应的glibc版本，都必须小于等于运行环境的glibc版本才能正常加载。你编译出的二进制明确依赖__libc_start_main@GLIBC_2.34，所以确实只能在libc >= 2.34的系统上运行，放到libc 2.31的环境会直接报version 'GLIBC_2.34' not found的加载错误。

2. 兼容libc >= 2.31的解决方案 #

你添加的__asm__指令不生效的核心原因是缺少对应C++的函数声明，2.34版本的glibc修改了__libc_start_main的ABI，没有显式声明的话编译器会默认匹配新版符号，手动指定的版本会被忽略，你可以选择以下任意一种方案解决：

• 方案一：手动绑定旧版符号
  修改代码添加extern "C"声明适配C++编译规则：

__asm__(".symver __libc_start_main, __libc_start_main@GLIBC_2.2.5");
extern "C" int __libc_start_main(int (*main)(int, char**, char**), int argc, char** argv, int (*init)(int, char**, char**), void (*fini)(void), void (*rtld_fini)(void), void* stack_end);

int main() {
  return 0;
}

使用如下命令编译：
g++ -o app app.cpp -Wl,--default-symver
编译完成后用nm -D app验证，可以看到__libc_start_main的依赖版本变成2.2.5，所有libc >=2.2.5的系统都可以运行，自然覆盖2.31及以上版本。

• 方案二：静态编译相关依赖
  如果你的程序没有复杂的动态库依赖，直接静态编译相关依赖库，完全不依赖系统的glibc版本：
  g++ -o app app.cpp -static-libgcc -static-libstdc++ -static
  该方案生成的二进制可以在所有同架构Linux系统上运行，唯一缺点是二进制体积会比动态编译大。
• 方案三：使用匹配版本的构建环境
  最稳妥不会出兼容问题的方案是直接用最低兼容目标的环境做构建，比如使用自带libc 2.31的Ubuntu 20.04容器/虚拟机编译，生成的二进制天然兼容所有libc >=2.31的系统，不需要手动修改任何符号配置。

内容的提问来源于stack exchange，提问作者ralvento