如何在新版Linux构建兼容低版本libc的程序？

问题场景 #

我在Fedora 35（glibc 2.34）上编译了一个最简C程序：

$ cat test.c
int main(int argc, char **argv)
{
}

$ cc test.c

生成的a.out在旧系统（比如Ubuntu 20）运行时报错，因为旧系统glibc版本低于2.34：

$ ./a.out
./a.out: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./a.out)

通过readelf可以看到程序依赖了高版本的glibc符号：

$ readelf --dyn-sym a.out

Symbol table '.dynsym' contains 3 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.34 (2)
     2: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__

解决方案 #

1. 静态编译（最简单方案） #

直接将glibc等依赖库静态链接到程序中，脱离对系统动态库的依赖。编译时添加-static参数：

$ cc -static test.c

生成的程序可在几乎所有同架构Linux系统运行，但缺点是程序体积会明显增大，且无法自动获取系统库的安全更新。

2. 指定旧版glibc文件编译 #

如果需要保留动态链接特性，可以在编译时指定旧版glibc的头文件和库路径：

• 先获取目标旧版系统的glibc头文件与库文件（比如Ubuntu 20对应的glibc 2.31）
• 编译时通过参数指定路径：

$ cc test.c -I/path/to/old-glibc/include -L/path/to/old-glibc/lib -Wl,--rpath=/path/to/old-glibc/lib -Wl,--dynamic-linker=/path/to/old-glibc/lib/ld-linux-x86-64.so.2

这种方式需要自行维护旧版glibc文件，适合对动态链接有需求的场景。

3. 容器编译（通用推荐方案） #

利用旧版系统的容器（比如Ubuntu 20的Docker镜像）作为编译环境，直接在旧版系统环境中编译程序，生成的产物天然兼容旧版系统：

# 拉取Ubuntu 20镜像
$ docker pull ubuntu:20.04
# 挂载当前目录到容器内编译
$ docker run -v $(pwd):/workdir -w /workdir ubuntu:20.04 gcc test.c

这种方式无需手动处理库依赖，是最省心的跨版本兼容方案。

4. 兼容性编译选项 #

部分新版本gcc支持通过特定选项降低glibc版本依赖，比如--default-symver可以强制使用通用符号版本，但仅适用于部分场景：

$ cc test.c -Wl,--default-symver

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