根据我的理解，C 库必须与编译器一起分发。例如，GCC 必须分发它自己的 C 库，而 Forte 必须分发它自己的 C 库。我的理解正确吗？
但是，用 GCC 编译的用户库可以与 Forte C 库一起使用吗？如果系统中存在这两个 C 库，那么在运行时将调用哪一个？
此外，如果应用程序链接到多个库，其中一些是用 GCC 编译的，一些是用 Forte 编译的，那么用 GCC 编译的库是否会自动链接到 GCC C 库，并且对于 Forte 的行为是否相同。
GCC 附带 libgcc，其中包含辅助函数来执行长除法等操作（甚至更简单的操作，例如在没有乘法指令的 CPU 上进行乘法）。 它不需要特定的 libc 实现。 FreeBSD 使用 BSD 的派生版本，glibc 在 Linux 上非常流行，并且有针对嵌入式系统的特殊版本，例如 avr-libc。
系统可以安装许多库（libc 和其他），并且选择它们的规则因操作系统而异。 如果静态链接，它完全在编译时确定。 如果您动态链接，则会发挥版本控制和路径规则的作用。 通常，您无法在运行时混合和匹配，因为库的某些部分（来自标头）已编译到可执行文件中。
如果两个编译器都遵循平台的 ABI，那么它们的编译产品应该是兼容的。 这就是定义特定寄存器和调用约定的目的。
就 Solaris 而言，您的假设是不正确的。标准C库作为内核和用户层之间的接口，随操作系统一起提供。这意味着无论您使用什么 C 编译器（Forte/studio 或 gcc），始终使用相同的 libc。无论如何，Gnu 标准 C 库 (glibc) 到 Solaris 的罕见移植非常有限，并且可能缺少太多可用功能。 http://csclub.uwaterloo.ca/~dtbartle/opensolaris/
其他答案都没有提到促进编译器和库之间互操作的重要功能 - ABI 或应用程序二进制接口。 在类Unix机器上，有一个完善的ABI，系统上的C编译器都遵循ABI。 这允许大量的混合搭配。 通常，您使用系统提供的 C 库，但您可以使用编译器提供的替换版本，或单独创建的版本。 通常，您可以将一个编译器编译的库与其他编译器编译的程序一起使用。
有时，一个编译器使用运行时支持库来执行某些操作 - 也许是 32 位机器上的 64 位算术例程。 如果您将使用此编译器构建的库用作使用另一个编译器构建的程序的一部分，则可能需要链接该库。 然而，对于纯 C，我已经很长时间没有将其视为问题了。
链接 C++ 是另一回事。 不同的 C++ 编译器之间没有相同程度的互操作 - 它们在类布局（虚函数表等）的细节以及如何完成异常处理等方面存在分歧。 您必须更加努力地创建使用一个 C++ 编译器构建的可供其他人使用的库。
C 库中只有少数内容是强制性的，因为独立环境不需要它们。它只需提供标题所需的内容
<float.h>, <iso646.h>, <limits.h>, <stdarg.h>, <stdbool.h>, <stddef.h>, and <stdint.h>
这些通常不会实现很多必须提供的功能。
另一种类型的环境称为“托管”环境。正如名称所示，他们假设有某个实体“托管”正在运行的程序，通常是操作系统。因此，通常 C 库是由“托管环境”提供的，但正如 Ben 所说，在不同的系统上甚至可能有替代的实现。
强效？真的很老了
Solaris 的首选编译器和开发人员工具都包含在 Oracle Solaris Studio 中。 C/C++/Fortran，带有调试器、性能分析器和基于 NetBeans 的 IDE，以及大量库。
http://www.oracle.com/technetwork/server-storage/solarisstudio/index.html
它（仍然）也是免费的。
我认为术语有些混乱：库不是 DLL 或 .so：在编程语言的真正意义上，库是编译后的代码，链接器将与我们的二进制文件 (.o) 合并。因此链接器（或通过某些指令的编译器......）可以管理它们，但操作系统不能，根本不是与操作系统相关的概念。
我们习惯于认为操作系统是用 C 编写的，我们可以使用 gcc/库或类似的库来重建操作系统，但 C 不是 linux / unix。
我们还可以有一个用 Pascal 编写的操作系统（Mac OS 在很多年前就是这种方式......）并使用带有我们最喜欢的 C 编译器的库，或者有一个用 ASM 编写的操作系统（即使不是全部，就像第一个 Windows 版本一样） ），但是我们必须有 C 库才能构建 exe。