进程链接是否仍会加载 libc.a 中的文件？
Does process linking still load o files in libc.a?
我正在看这个 lecture note（幻灯片 #6）：
file.o包含外部符号和定义符号
libc.a 包含所有库函数的 .o 文件。
链接过程：扫描 libc.a 以查找由 file.o 声明的外部符号，加载适当的 .o 文件。
ar -t /usr/lib/libc.a # lists all the .o files in libc.a
但是在我的 CentOS 7 主机上我什么也看不到。
$ ar -t /usr/lib/libc.a
ar: /usr/lib/libc.a: No such file or directory
But on my CentOS 7 host I don't see anything.
寻找 /usr/lib64/libc.a。还要了解如何查找文件：研究 man find 和 man locate 可能会对您将来有所帮助。
也就是说，您的笔记描绘了一个明显不正确的画面。
首先，大多数现代编译器都集成了预处理器。 cccp / gcc -E 阶段通常不作为单独的阶段执行。相反，预处理器是 运行 作为正常编译的一部分，它的输出会立即被 gcc -c 阶段消耗。
其次，大多数现代 Unix / Linux 系统使用共享库，这意味着 libc.a 永远不会 linked，并且 libc.so.6 用于解析符号反而。 （因此，libc.a 可能甚至没有安装在您的系统上。）
您的笔记确实提到了 ld.so 和 libc.so，因此讲师希望使用动态 linking。不清楚他/她为什么提到 libc.a，因为它没有在动态 linking 案例中使用。
这个：
ld.so is the dynamic linker: turns an a.out into a process.
也是不正确的：进程exists before ld.so starts 运行ning.
关于 printf 静态 linked 到可执行文件 file1 和 file2 的部分，然后从 link 到 __vsprintf libc.so 在遥远的过去可能是正确的，但在任何最近的 Linux 系统中都不正确。
后面可能还有更多误导性的 "facts"。 TL;DR：这些注释在太多细节上是错误的，实际上没有用。
我正在看这个 lecture note（幻灯片 #6）：
file.o包含外部符号和定义符号
libc.a 包含所有库函数的 .o 文件。
链接过程：扫描 libc.a 以查找由 file.o 声明的外部符号，加载适当的 .o 文件。
ar -t /usr/lib/libc.a # lists all the .o files in libc.a
但是在我的 CentOS 7 主机上我什么也看不到。
$ ar -t /usr/lib/libc.a
ar: /usr/lib/libc.a: No such file or directory
But on my CentOS 7 host I don't see anything.
寻找 /usr/lib64/libc.a。还要了解如何查找文件：研究 man find 和 man locate 可能会对您将来有所帮助。
也就是说，您的笔记描绘了一个明显不正确的画面。
首先，大多数现代编译器都集成了预处理器。 cccp / gcc -E 阶段通常不作为单独的阶段执行。相反，预处理器是 运行 作为正常编译的一部分，它的输出会立即被 gcc -c 阶段消耗。
其次，大多数现代 Unix / Linux 系统使用共享库，这意味着 libc.a 永远不会 linked，并且 libc.so.6 用于解析符号反而。 （因此，libc.a 可能甚至没有安装在您的系统上。）
您的笔记确实提到了 ld.so 和 libc.so，因此讲师希望使用动态 linking。不清楚他/她为什么提到 libc.a，因为它没有在动态 linking 案例中使用。
这个：
ld.so is the dynamic linker: turns an a.out into a process.
也是不正确的：进程exists before ld.so starts 运行ning.
关于 printf 静态 linked 到可执行文件 file1 和 file2 的部分，然后从 link 到 __vsprintf libc.so 在遥远的过去可能是正确的，但在任何最近的 Linux 系统中都不正确。
后面可能还有更多误导性的 "facts"。 TL;DR：这些注释在太多细节上是错误的，实际上没有用。