为何用-lc与自定义汇编编译可规避GLIBC版本依赖问题？

使用gcc -g a.c -lz -o normal编译代码后在Debian服务器运行时，出现报错：

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

但改用gcc -g a.c -lz -lc -nostdlib my.s -o alt编译后，程序可正常运行。询问该现象的原因，以及能否无需编写自定义启动函数实现同样效果。

相关代码 #

a.c 代码

#include <zlib.h>
int main() {
    z_stream s;
    memset(&s, 0, sizeof(z_stream));
    return deflateInit(&s, 7);
}

my.s 代码

.globl _start
_start:
    call main
    mov %rax, %rdi
    mov $60, %rax
    syscall

常规编译失败的核心原因 #

用gcc -g a.c -lz -o normal编译时，GCC默认会链接一套标准C库启动代码（如crt0.o、crti.o、crtn.o）。这些启动代码通常是在高版本GLIBC环境下编译生成的，会依赖GLIBC_2.34这类高版本符号，而你的Debian服务器上安装的GLIBC版本低于2.34，导致运行时触发版本不兼容错误。
另外，你链接的zlib库（-lz）如果是在高版本GLIBC环境下编译的，常规链接方式会让程序间接依赖高版本GLIBC的符号，进一步加剧这个问题。

自定义启动代码编译正常的原理 #

-nostdlib参数告诉GCC不要链接默认的标准启动代码和标准库，之后你手动指定-lc链接系统C库、-lz链接zlib，再加上自定义的_start启动函数（my.s）：

1. 跳过了GCC默认的高版本依赖启动代码，避免了对GLIBC_2.34的强制依赖；
2. 手动链接C库时，会优先使用服务器上已安装的低版本GLIBC中的符号——只要你程序用到的C库函数（比如memset、deflateInit依赖的底层接口）在低版本GLIBC中存在，就能正常运行；
3. 自定义的_start函数直接调用main，然后通过系统调用exit返回，完全替代了标准启动代码的功能，且没有额外版本依赖。

不用写汇编代码，通过以下GCC参数就能达到同样效果：

• 使用-nostartfiles参数：
  这个参数会跳过标准启动代码，但保留标准C库的链接。编译命令改为：

  gcc -g a.c -lz -nostartfiles -o alt
  

  原理和自定义启动代码一致：跳过依赖高版本GLIBC的启动代码，直接以main作为程序入口，GCC会自动处理返回值并调用exit，无需手动写汇编。

• 静态链接GLIBC：
  使用-static参数将所有依赖库（包括GLIBC）静态打包到可执行文件中，彻底脱离对系统动态GLIBC的依赖：

  gcc -g a.c -lz -static -o normal_static
  

  注意：静态链接会增大可执行文件体积，且部分依赖动态库的系统功能（如NSS域名解析）可能无法正常工作，但能彻底解决版本兼容问题。

• 指定低版本GLIBC链接路径：
  如果能获取到低版本GLIBC的开发库文件，可以通过-L指定库路径、-I指定头文件路径，强制GCC链接低版本GLIBC。不过这种方法需要提前准备对应版本的库，操作复杂度较高，一般不推荐。

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