探索 Linux 上 C 库的起源与演变

linux

一个直接使用syscall的纯汇编linux程序，可以完全不依赖任何共享库（so库），甚至不需要常见的ld-linux*.so或libc.so。虽然libc.so并非必须，但99%的程序都会引用它。glibc是一个用户态项目，与linux内核没有直接关系。libc封装了系统调用（syscall）API，并提供了一些C语言标准函数。然而，glibc确实与linux用户态环境紧密绑定，因为linux程序如果需要引用外部共享库，就必须加载ld-linux*.so，而这个动态链接器本身就是glibc的一部分。因此，绝大多数linux程序在运行时都会间接引用libc。有人可能会问：既然glibc并不是linux专属，那么C库中的系统调用是如何准确调用的？ 实际上，glibc几乎只适用于linux，只有部分C标准库函数的代码可以勉强跨平台使用。ld-linux.so的源码也包含在glibc中，它专为linux设计。linux的系统调用与库无关，通过直接嵌入syscall汇编代码即可实现。还有人会问：linux内核源码中似乎没有glibc，为什么我编译出的linux内核可以直接运行C程序？这些程序使用的glibc是什么时候出现的？是哪个版本？是否随linux内核源码一起发布？ 答案是：glibc仅存在于用户态，内核本身并不需要它。例如，ld-linux的功能代码只服务于linux用户态环境。glibc的libc.so是用户态程序的核心依赖，几乎所有程序都会引用它，包括关机命令、终端服务和图形界面等。glibc的版本由发行版维护者选择并提供，与内核源码无关。除了glibc，还有其他轻量级的C库实现，例如musl libc，它提供了类似的系统调用封装和C标准库支持，但更加注重简单性和兼容性。