为何编译可执行文件阶段需要依赖共享库？

这问题问得太到位了！刚接触动态链接的开发者几乎都会有这个疑惑——既然共享库是运行时才加载的，为啥编译的时候还得有它？我结合你的实验给你掰扯清楚：

先搞懂编译链接的两个核心阶段 #

咱们用gcc -o main main.c -L. -lfoo这条命令的时候，其实干了两件事：

1. 编译阶段：把main.c转换成机器码目标文件main.o。这一步其实不需要共享库，只要你有函数的声明（比如头文件里的void foo();），编译器就知道怎么生成调用foo的指令，不会报错。
2. 链接阶段：把main.o和需要的库链接成最终的可执行文件main。这一步就是你实验报错的关键！

链接阶段到底需要共享库做什么？ #

链接器的核心任务之一是解析所有未定义的符号——比如你在main.c里调用了foo()，这个函数的实现不在main.o里，链接器必须确认：这个符号确实存在于某个库中，而且能被正确找到。

共享库（比如libfoo.so）里不仅有实际的机器码，还有一份符号表，记录了库中所有函数、变量的名字和地址信息。链接器会去读取这份符号表，验证foo这个符号存在，然后在生成的可执行文件里写入两个关键信息：

• 该可执行文件依赖libfoo.so这个共享库
• foo这个符号需要从libfoo.so中加载

如果链接器找不到libfoo.so（比如你改成了libfar.so），它就没法验证foo符号的存在，自然会抛出undefined reference错误——毕竟它不能凭空相信你说“这个函数肯定存在”，必须拿到实锤。

再用实验验证拆分步骤 #

你可以试试拆分命令操作：

1. 先编译生成目标文件：gcc -c main.c
   这时候不管有没有libfoo.so，都不会报错，因为编译器只需要知道foo的声明（比如你写在代码里或者头文件里），就能生成调用指令。
2. 再尝试链接：gcc -o main main.o -L. -lfoo
   这时候如果libfoo.so不在当前目录（或者改了名），链接器就会报错，和你之前遇到的情况一模一样。

最后总结一下 #

• 编译（生成目标文件）：只需要函数/变量的声明（头文件即可），不需要共享库
• 链接（生成可执行文件）：必须有共享库，用来验证符号存在，并记录依赖关系
• 运行阶段：需要共享库存在（在系统默认路径或者你指定的路径），动态加载器会根据可执行文件里的依赖信息加载库，解析符号并执行

内容的提问来源于stack exchange，提问作者Gab是好人