C 库是与编译器一起分发还是直接由操作系统分发？
根据我的理解，C 库必须与编译器一起分发。例如，GCC 必须分发它自己的 C 库，而 Forte 必须分发它自己的 C 库。我的理解正确吗？
但是，用 GCC 编译的用户库可以与 Forte C 库一起使用吗？如果系统中存在这两个 C 库，那么在运行时将调用哪一个？
此外，如果应用程序链接到多个库，其中一些是用 GCC 编译的，一些是用 Forte 编译的，那么用 GCC 编译的库是否会自动链接到 GCC C 库，并且对于 Forte 的行为是否相同。
As per my understanding, C libraries must be distributed along with compilers. For example, GCC must be distributing it's own C library and Forte must be distributing it's own C library. Is my understanding correct?
But, can a user library compiled with GCC work with Forte C library? If both the C libraries are present in a system, which one will get invoked during run time?
Also, if an application is linking to multiple libraries some compiled with GCC and some with Forte, will libraries compiled with GCC automatically link to the GCC C library and will it behave likewise for Forte.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
GCC 附带 libgcc，其中包含辅助函数来执行长除法等操作（甚至更简单的操作，例如在没有乘法指令的 CPU 上进行乘法）。它不需要特定的 libc 实现。 FreeBSD 使用 BSD 的派生版本，glibc 在 Linux 上非常流行，并且还有针对嵌入式系统的特殊版本，例如 avr-libc。
系统可以安装许多库（libc 和其他），并且选择它们的规则因操作系统而异。如果静态链接，它完全在编译时确定。如果您动态链接，则会发挥版本控制和路径规则的作用。通常，您无法在运行时混合和匹配，因为库的某些部分（来自标头）已编译到可执行文件中。
如果两个编译器都遵循平台的 ABI，那么它们的编译产品应该是兼容的。这就是定义特定寄存器和调用约定的目的。
GCC comes with libgcc which includes helper functions to do things like long division (or even simpler things like multiplication on CPUs with no multiply instruction). It does not require a specific libc implementation. FreeBSD uses a BSD derived one, glibc is very popular on Linux and there are special ones for embedded systems like avr-libc.
Systems can have many libraries installed (libc and other) and the rules for selecting them vary by OS. If you link statically it's entirely determined at compile time. If you link dynamically there are versioning and path rules which come into play. Generally you cannot mix and match at runtime because of bits of the library (from headers) that got compiled into the executable.
The compile products of two compilers should be compatible if they both follow the ABI for the platform. That's the purpose of defining specific register and calling conventions.
就 Solaris 而言，您的假设是不正确的。标准C库作为内核和用户层之间的接口，随操作系统一起提供。这意味着无论您使用什么 C 编译器（Forte/studio 或 gcc），始终使用相同的 libc。无论如何，Gnu 标准 C 库 (glibc) 到 Solaris 的罕见移植是相当有限的，并且可能缺少太多可用的功能。 http://csclub.uwaterloo.ca/~dtbartle/opensolaris/
As far as Solaris is concerned, you assumption is incorrect. Being the interface between the kernel and the userland, the standard C library is provided with the operating system. That means whatever C compiler you use (Forte/studio or gcc), the same libc is always used. In any case, the rare ports of the Gnu standard C library (glibc) to Solaris are quite limited and probably lacking too much features to be usable. http://csclub.uwaterloo.ca/~dtbartle/opensolaris/
其他答案都没有提到促进编译器和库之间互操作的重要功能 - ABI 或应用程序二进制接口。在类Unix机器上，有一个完善的ABI，系统上的C编译器都遵循ABI。这允许大量的混合搭配。通常，您使用系统提供的 C 库，但您可以使用编译器提供的替换版本，或单独创建的版本。通常，您可以将一个编译器编译的库与其他编译器编译的程序一起使用。
有时，一个编译器使用运行时支持库来执行某些操作 - 也许是 32 位机器上的 64 位算术例程。如果您将使用此编译器构建的库用作使用另一个编译器构建的程序的一部分，则可能需要链接该库。然而，对于纯 C，我已经很长时间没有将其视为一个问题了。
链接 C++ 是另一回事。不同 C++ 编译器之间的互操作程度不同 - 它们在类布局（虚函数表等）的细节以及如何完成异常处理等方面存在分歧。您必须更加努力地创建使用一个 C++ 编译器构建的可供其他人使用的库。
None of the other answers (yet) mentions an important feature that promotes interworking between compilers and libraries - the ABI or Application Binary Interface. On Unix-like machines, there is a well documented ABI, and the C compilers on the system all follow the ABI. This allows a great deal of mix'n'match. Normally, you use the system-provided C library, but you can use a replacement version provided with a compiler, or created separately. And normally, you can use a library compiled by one compiler with programs compiled by other compilers.
Sometimes, one compiler uses a runtime support library for some operations - perhaps 64-bit arithmetic routines on a 32-bit machine. If you use a library built with this compiler as part of a program built with another compiler, you may need to link this library. However, I've not seen that as a problem for a long time - with pure C.
Linking C++ is a different matter. There isn't the same degree of interworking between different C++ compilers - they disagree on details of class layout (vtables, etc) and on how exception handling is done, and so on. You have to work harder to create libraries built with one C++ compiler that can be used by others.
C 库中只有少数内容是强制性的，因为独立环境不需要它们。它只需要提供标头所需的内容，
这些通常不会实现许多必须提供的功能。
另一种类型的环境称为“托管”环境。正如名称所示，他们假设有某个实体“托管”正在运行的程序，通常是操作系统。因此，通常 C 库是由“托管环境”提供的，但正如 Ben 所说，在不同的系统上甚至可能有替代的实现。
Only few things of the C library are mandatory in the sense that they are not needed for a freestanding environment. It only has to provide what is necessary for the headers
These usually don't implement a lot of functions that must be provided.
The other type of environments are called "hosted" environments. As the name indicated they suppose that there is some entity that "hosts" the running program, usually the OS. So usually the C library is provided by that "hosting environment", but as Ben said, on different systems there may even be alternative implementations.
长处？那真的很老了。
Solaris 的首选编译器和开发人员工具都包含在 Oracle Solaris Studio 中。
C/C++/Fortran，带有调试器、性能分析器和基于 NetBeans 的 IDE，以及大量库。
http://www.oracle.com/technetwork/server-storage/solarisstudio /index.html
它（仍然）也是免费的。
Forte? That's really old.
The preferred compilers and developer tools for Solaris are all contained in Oracle Solaris Studio.
C/C++/Fortran with a debugger, performance analyzer, and IDE based on NetBeans, and lots of libraries.
http://www.oracle.com/technetwork/server-storage/solarisstudio/index.html
It's (still) free, too.
我认为术语有些混乱：库不是 DLL 或 .so：在编程语言的真正意义上，库是编译后的代码，链接器将与我们的二进制文件合并（.o ）。因此链接器（或通过某些指令的编译器......）可以管理它们，但操作系统不能，根本不是与操作系统相关的概念。
我们习惯于认为操作系统是用 C 编写的，我们可以使用 gcc/库或类似的库来重建操作系统，但 C 不是 linux / unix。
我们还可以有一个用 Pascal 编写的操作系统（Mac OS 很多年前就是这种方式......）并使用带有我们最喜欢的 C 编译器的库，或者有一个用 ASM 编写的操作系统（即使不是全部，如第一个 Windows 版本） ，但是我们必须有 C 库才能构建 exe。
I think there a is a bit of confusion about terms: a library is NOT DLL's or .so: in the real sense of programming languages, Libraries are compiled code the LINKER will merge with our binary (.o). So the linker (or the compiler via some directives...) can manage them, but OS can't, simply is NOT a concept related to OS.
We are used to think OSes are written in C and we can rebuild the OS using gcc/libraries or similar, but C is NOT linux / unix.
We can also have an OS written in Pascal (Mac OS was in this manner many years ago..) AND use libraries with our favorite C compiler, OR have an OS written in ASM (even if not all, as in first Windows version), but we must have C libraries to build an exe.