glibc 是 Linux 的标准库，是不是在 Linux 上编译出的程序，底层都会和 glibc 有关联？
piqizhu8 2021-03-06 16:25:15 +08:00 2542 次点击这是一个创建于 1690 天前的主题，其中的信息可能已经有所发展或是发生改变。
我的理解是：
glibc 提供了标准接口（便于程序员调用），
我们开发的软件，通过调用 glibc 的接口， 间接实现了 控制操作系统
那是不是说明， 如果移除了 glibc，Linux 上的软件就无法运行了？
而借助 glibc，我们就可以实现自己的编程语言？
而由于 glibc 是 c 语言实现的， 那我们实现的编程语言（假设 z 语言），z 语言开发的程序，z 编译器必然要把 z 代码翻译成 c 语言代码 ，再由 c 编译器 编译成可执行程序？
请问我的理解对吗？
哪里错了，我该补充什么知识呢
谢谢
 | 1 billlee 2021-03-06 16:54:05 +08:00  2 libc 里面的接口可以分为两类，POSIX 标准定义的系统调用（ man 手册的第 2 章），以及 C 标准定义的库函数（ man 手册的第 3 章）。 控制操作系统必须通过系统调用，所以 libc 理论上是必须的。但是，有些语言，如 golang 绕过了 libc 直接实现了对内核的系统调用，这样的好处是不依赖 libc, 但问题是 POSIX 只定义了系统调用的 C 接口，这样实现相当于依赖内核的不稳定接口。 z 语言的编译器不需要把 z 代码翻译成 C 代码。只需要在系统调用时按 C 语言的调用约定去调用 libc 就可以了。 libc 有很多不同的实现，glibc 只是其中一种。 |
 | 2 pkookp8 2021-03-06 17:20:17 +08:00 1 内核也是一个软件，也是一个大库。驱动就可以动态加载，调用一些内核接口。 没有 glibc，把驱动当一般软件写，也不是不行 |
 | 3 minami 2021-03-06 18:18:01 +08:00 1 可以不依赖 glibc，比如静态链接编译一个 busybox，就可以不依赖 glibc 运行许多常规命令了。除了静态链接，还可以选择 glibc 以外的 C 运行库，比如用 musl 编译 busybox 。在 linux 平台上，只要和系统调用打交道，应该最终都必须依赖 C 标准库，可以不是 glibc，如 alpine linux 就使用 musl 。 至于你说的“如果移除了 glibc，Linux 上的软件就无法运行了？”，请移步《如何拯救一台 glibc 被干掉的 Linux 服务器?》一文。答案是，在常见的发行版上，确实就几乎等于凉了，如果把运行的 ssh 也关掉的话，就再也 ssh 不上去了，凉透了，doge |
 | 4 msg7086 2021-03-06 18:40:06 +08:00 2 和系统打交道，根本上是系统调用。（ Windows 上则是 Windows API 。） 只不过 libc 把系统调用给你封装好了，然后你只要用 C 语言调用一下函数就行了。 当然你也可以自己从头实现一遍 libc 自己用。 glibc 用 C 语言实现，和其他语言怎么调用 glibc 完全没关系。有种东西叫 API，只要你按照 API 调用规范来写程序，什么语言都能互相调用。比如 Java 可以走 JNI 调用 C 库，根本不需要把 Java 程序编译成 C 。 |
 | 5 liuminghao233 2021-03-06 21:30:51 +08:00 via iPhone 你可以把参数放寄存器然后自己 syscall |
 | 6 Claar 2021-03-06 22:04:24 +08:00 via iPhone 本质应该是系统调用 libc 是基于系统调用的通用功能实现 就像 tls 库，你固然可以自己实现，但是外面有人专门去维护你为什么要专门自己实现一次 如果你把调用其他人写的库理解为运行他人的函数就很容易理解了，无论你写的程序是用什么语言，当你调用 libc 库的时候你都是把 cpu 控制权临时转移给了库函数，他本质是一堆操作（指令）的集合体，用什么语言写的根本不重要 |
Select Language