glibc 是 Linux 的标准库，是不是在 Linux 上编译出的程序，底层都会和 glibc 有关联？

[piqizhu8]

我的理解是：

glibc 提供了标准接口（便于程序员调用），
我们开发的软件，通过调用 glibc 的接口， 间接实现了 控制操作系统

那是不是说明， 如果移除了 glibc，Linux 上的软件就无法运行了？

而借助 glibc，我们就可以实现自己的编程语言？

而由于 glibc 是 c 语言实现的， 那我们实现的编程语言（假设 z 语言），z 语言开发的程序，z 编译器必然要把 z 代码翻译成 c 语言代码 ，再由 c 编译器 编译成可执行程序？

请问我的理解对吗？

哪里错了，我该补充什么知识呢

谢谢

[billlee]

libc 里面的接口可以分为两类，POSIX 标准定义的系统调用（ man 手册的第 2 章），以及 C 标准定义的库函数（ man 手册的第 3 章）。

控制操作系统必须通过系统调用，所以 libc 理论上是必须的。但是，有些语言，如 golang 绕过了 libc 直接实现了对内核的系统调用，这样的好处是不依赖 libc, 但问题是 POSIX 只定义了系统调用的 C 接口，这样实现相当于依赖内核的不稳定接口。

z 语言的编译器不需要把 z 代码翻译成 C 代码。只需要在系统调用时按 C 语言的调用约定去调用 libc 就可以了。

libc 有很多不同的实现，glibc 只是其中一种。

[pkookp8]

内核也是一个软件，也是一个大库。驱动就可以动态加载，调用一些内核接口。
没有 glibc，把驱动当一般软件写，也不是不行

[minami]

可以不依赖 glibc，比如静态链接编译一个 busybox，就可以不依赖 glibc 运行许多常规命令了。除了静态链接，还可以选择 glibc 以外的 C 运行库，比如用 musl 编译 busybox 。在 linux 平台上，只要和系统调用打交道，应该最终都必须依赖 C 标准库，可以不是 glibc，如 alpine linux 就使用 musl 。
至于你说的“如果移除了 glibc，Linux 上的软件就无法运行了？”，请移步《如何拯救一台 glibc 被干掉的 Linux 服务器?》一文。答案是，在常见的发行版上，确实就几乎等于凉了，如果把运行的 ssh 也关掉的话，就再也 ssh 不上去了，凉透了，doge

[msg7086]

和系统打交道，根本上是系统调用。（ Windows 上则是 Windows API 。）
只不过 libc 把系统调用给你封装好了，然后你只要用 C 语言调用一下函数就行了。
当然你也可以自己从头实现一遍 libc 自己用。

glibc 用 C 语言实现，和其他语言怎么调用 glibc 完全没关系。有种东西叫 API，只要你按照 API 调用规范来写程序，什么语言都能互相调用。比如 Java 可以走 JNI 调用 C 库，根本不需要把 Java 程序编译成 C 。

[liuminghao233]

你可以把参数放寄存器然后自己 syscall

[Claar]

本质应该是系统调用
libc 是基于系统调用的通用功能实现
就像 tls 库，你固然可以自己实现，但是外面有人专门去维护你为什么要专门自己实现一次
如果你把调用其他人写的库理解为运行他人的函数就很容易理解了，无论你写的程序是用什么语言，当你调用 libc 库的时候你都是把 cpu 控制权临时转移给了库函数，他本质是一堆操作（指令）的集合体，用什么语言写的根本不重要