linker - 进程链接是否仍会在 libc.a 中加载 o 文件？

Question

我在看这个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

Answer 1

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从未链接，并且 libc.so.6用于解析符号。 (因此，libc.a 甚至可能没有安装在您的系统上。)

确实，您的笔记提到了ld.so和 libc.so ，所以讲师希望使用动态链接。不清楚他/她为什么提到libc.a根本没有，因为它没有用于动态链接案例。

这个:

ld.so is the dynamic linker: turns an a.out into a process.

也不正确:进程存在于ld.so之前开始运行。

关于printf的部分静态链接到可执行文件 file1和 file2 , 然后都链接到 __vsprintf来自 libc.so在遥远的过去可能是正确的，但在任何最近的 Linux 系统上都不正确。

可能还有更多误导性的“事实”。 TL；DR:这些注释在太多细节上是错误的，实际上没有用。