glibc 和 POSIX 究竟是什么？
What is glibc and POSIX exactly?
我真的很困惑。请看下面的图片：
我发现 linux 中有一个名为 glibc 的库，当我们执行 c/c++ 程序时，我们使用它的函数并调用适当的系统调用。实际上我们可以使用API。但我很困惑。 glibc 是否将我们用于 c/c++ 程序的操作系统放入其中？因此，当我们编写 python/ruby/... 程序时，没有标准库或 API ，例如 glibc，我们调用它的函数并调用适当的系统调用。那么我们的代码如何在python/ruby/...运行？另外，什么是POSIX？我看了维基百科，但我看不懂。它与 glibc 有什么关系？请给我一些我能找到的例子和简单的解释
POSIX 是一种计算机标准，用于标准化操作系统。否则操作系统将完全不同并且它们之间不会有任何共同点（有点像微软对 Windows 所做的）。开放标准（与 Windows 不同）以某些复杂的方式使计算更容易获得且更实惠。今天，您可能认为 Linux 在某些方面是一个促进开源计算和 free/affordable 计算的非营利组织。 Linux 的网站大多在 .org 中，因为它们是促进开放计算工作的有机体。
同时，UNIX 是一个 POSIX 兼容的操作系统。
由于 glibc 在 Linux 上工作并且 Linux 非常类似于 UNIX（请参阅 https://www.quora.com/Is-Linux-compatible-with-UNIX), then glibc should work on UNIX systems. Since UNIX is POSIX compliant (see https://linuxhint.com/is_linux_posix_compliant/），因此 Linux 大部分 POSIX 兼容。
关于所有相关内容，您可以在 cs.stackexchange.com 此处 https://cs.stackexchange.com/questions/136298/how-are-kernels-and-operating-systems-in-general-written-in-c/136330#136330 查看我的回答。
When you write a C app on Linux, you include headers from glibc to use the standard functions like malloc, fork etc. When you compile your app, you either compile it statically or dynamically. When you compile it statically, you include all the kernel code in the executable like mmap's code. Basically, when mmap is called from your main function, the CPU jumps to the function which is mapped in virtual memory. Where it "stops" including the code, is when you jump to kernel code using int 0x80 on older x86 32 bits processors. I don't know about the system call convention for x86-64 honestly. It is probably similar. When your code calls int 0x80 on x86, it interrupts the CPU and it jumps to shared-by-all-processes kernel code. This kernel code cannot be included in your executable because it is interrupt code. So mmap is included in your executable up until the system call. The rest of the work is done in the interrupt handler and then returns to mmap which now has the new address of the allocated memory chunk. mmap then returns to the glibc caller which, like you said, is a wrapper around kernel code calls. When you link dynamically, it is the same except linking happens just before runtime.
POSIX 与 glibc 相关，因为 POSIX 定义了标准 API，glibc 将调用该标准来实现 C 约定。这真是一个约定俗成的约定俗成。 C 约定是另一个约定。它说：如果你这样写，那么这应该是 运行 程序之后的结果。 Glibc 确实在寻求实现 C 约定，但在 POSIX 兼容系统上，如 Linux。
与此同时，Python/Ruby 等是高级语言，主要是用 C++/C 等低级语言编写的。运行 python 命令的 Python 程序是用 C 编写并编译的。然后你编写一个 Python 程序，然后在运行时由 C 程序解释。真的没有什么神奇的。这只是一个公约之上的公约。 POSIX 实现 glibc 用于实现 C 约定的系统调用标准，Python 用于实现 Python shell，后者在运行时解释您的 Python 程序.
我真的很困惑。请看下面的图片：
POSIX 是一种计算机标准，用于标准化操作系统。否则操作系统将完全不同并且它们之间不会有任何共同点（有点像微软对 Windows 所做的）。开放标准（与 Windows 不同）以某些复杂的方式使计算更容易获得且更实惠。今天，您可能认为 Linux 在某些方面是一个促进开源计算和 free/affordable 计算的非营利组织。 Linux 的网站大多在 .org 中，因为它们是促进开放计算工作的有机体。
同时，UNIX 是一个 POSIX 兼容的操作系统。
由于 glibc 在 Linux 上工作并且 Linux 非常类似于 UNIX（请参阅 https://www.quora.com/Is-Linux-compatible-with-UNIX), then glibc should work on UNIX systems. Since UNIX is POSIX compliant (see https://linuxhint.com/is_linux_posix_compliant/），因此 Linux 大部分 POSIX 兼容。
关于所有相关内容，您可以在 cs.stackexchange.com 此处 https://cs.stackexchange.com/questions/136298/how-are-kernels-and-operating-systems-in-general-written-in-c/136330#136330 查看我的回答。
When you write a C app on Linux, you include headers from glibc to use the standard functions like malloc, fork etc. When you compile your app, you either compile it statically or dynamically. When you compile it statically, you include all the kernel code in the executable like mmap's code. Basically, when mmap is called from your main function, the CPU jumps to the function which is mapped in virtual memory. Where it "stops" including the code, is when you jump to kernel code using int 0x80 on older x86 32 bits processors. I don't know about the system call convention for x86-64 honestly. It is probably similar. When your code calls int 0x80 on x86, it interrupts the CPU and it jumps to shared-by-all-processes kernel code. This kernel code cannot be included in your executable because it is interrupt code. So mmap is included in your executable up until the system call. The rest of the work is done in the interrupt handler and then returns to mmap which now has the new address of the allocated memory chunk. mmap then returns to the glibc caller which, like you said, is a wrapper around kernel code calls. When you link dynamically, it is the same except linking happens just before runtime.
POSIX 与 glibc 相关，因为 POSIX 定义了标准 API，glibc 将调用该标准来实现 C 约定。这真是一个约定俗成的约定俗成。 C 约定是另一个约定。它说：如果你这样写，那么这应该是 运行 程序之后的结果。 Glibc 确实在寻求实现 C 约定，但在 POSIX 兼容系统上，如 Linux。
与此同时，Python/Ruby 等是高级语言，主要是用 C++/C 等低级语言编写的。运行 python 命令的 Python 程序是用 C 编写并编译的。然后你编写一个 Python 程序，然后在运行时由 C 程序解释。真的没有什么神奇的。这只是一个公约之上的公约。 POSIX 实现 glibc 用于实现 C 约定的系统调用标准，Python 用于实现 Python shell，后者在运行时解释您的 Python 程序.