显式链接到 libc (-lc)答案

【问题标题】：Link explicitly to libc (-lc)显式链接到 libc (-lc)
【发布时间】：2021-11-09 03:11:41
【问题描述】：

在使用 libc 符号时，我是否应该将我的程序或库与 libc 显式链接？

即cc ... -lc

如果是程序，该问题适用于 Makefile，如果是库，则适用于 Makefile 和 pkg-config 文件。

附带一个问题：如果我根本不使用任何 libc 符号怎么办？那可能是一个非常没用的程序，但我很好奇。

我似乎记得有一些文章或书籍推荐这样做，但现在我找不到了。在任何情况下这样做或不这样做都会有问题？

编辑：

我通常使用gcc 和clang。（我还编辑了第三段以明确询问 Makefile 和 pkg-config 文件。）

【问题讨论】：

1.大多数编译器在调用链接器时会添加正确的标志以自动链接 libc。 2. 取决于编译器，但你仍然需要 libc 来处理 CRT 的东西，比如调用 main 的函数、从 main 返回后退出等。
您可能应该提及您正在使用的特定编译器
1) 我不熟悉任何不会自动隐式链接到 libc 的“主流”编译器。嵌入式系统的交叉编译器完全是另一回事。 2) 问：如果您不进行任何 libc 调用会怎样？答：链接器根本不会尝试链接大多数不需要的外部例程。这可能（也可能不会）影响可执行文件的大小。 3) 如果您愿意，一些编译器/链接器允许您显式排除标准库。例如：/docs.microsoft.com/en-us/cpp/build/reference/…
-lc 选项由cc 编译器/链接器前端自动提供给链接器。如果您使用cc 进行编译并使用ld 进行显式链接，则需要使用-lc 选项运行ld 以链接libc 库。

标签： c unix linker shared-libraries libc

【解决方案1】：

在使用 libc 符号时，我是否应该将我的程序或库与 libc 显式链接？

没有。来自POSIX cc：

标准 C 语言库自动可供 C 语言程序使用。

如果我根本不使用任何 libc 符号怎么办？

那么仍然不要显式链接 libc 并让编译器自动链接它。

在任何情况下这样做或不这样做都会有问题吗？

当您正在编写内核、裸机软件或其他特定于您正在使用的某些环境的低级程序时，并且您不想链接标准库。此外，当您不接受库的许可时。

【讨论】：

最后一段似乎更多地是关于何时不应链接到 libc，而不是不应明确要求链接到 libc（但当然，如果您不想链接，则可以'不要求它链接），但似乎是公平的完整性。
The last paragraph seems to be more about when one should not link against libc, more than if one should not explicitly ask to link against libc och 对，那么“隐式”链接和“显式和隐式”链接之间有区别吗？那么就没有区别了，答案就是“不”。
What about other languages 他们呢？ Those may be able to interface 他们为什么要交互？这些是其他语言，他们有自己的标准库或没有标准库，无论如何 C 对他们来说都不存在。 if I provided a static library? 太宽泛 - 静态库？
Does c++ link by default to libc also? C++ 编程语言是一种语言——它没有链接，它是一种语言。可能（可能不是）C++ STL 的特定实现需要具有来自 C 标准库的符号。这取决于该实施。实际上，要使用ostream，您必须拥有fopen，是的，默认情况下，C++ compilers 与 C++ 和 C 标准库链接。一门语言是完整的——书面结构和库，编译器应该提供它们。
我记得，c++ 作为可执行文件名称不是标准化的（在 POSIX 中）。这只是人们开始模仿cc 的事情，在这两种情况下，它只是指向真正可执行文件的链接（我的意思是，它不是编译器的名称）。无论哪种方式，clang++ 与 libc++ 链接，g++ 与 libstdcpp 链接。

【解决方案2】：

如果我根本不使用任何 libc 符号怎么办？

那么您的程序是独立的，不需要与标准库链接。

如果您使用gcc，则需要使用-nostdlib 命令行选项进行编译。

【讨论】：

嗯。程序int main(void) {} 没有（明确地）使用来自 C 标准库的任何符号，但它仍然可以为托管实现进行编译。我不同意一个程序是否引用标准库是它是否独立的标准。
由于“使用”的解释有点模棱两可，我认为这个答案在某种意义上是正确的，所以我赞成它，但我认为@JohnBollinger 建议的更多解释会很好。