为何创建共享库可省略-l依赖标志？两种编译方式差异解析

安全阿岳

2026-7-2

问题解答

为什么未加`-luv`能成功编译？

C编译分为编译（-c）和链接两个阶段：

编译阶段cc -fpic -g -c func.c仅负责将C代码转换为目标文件func.o，只做语法检查与代码生成，不会解析uv_close这类外部符号，只会在目标文件中标记这些符号为“未定义”。
链接成共享库时，Linux链接器默认允许共享库存在未定义符号（这是共享库与可执行文件的核心区别：可执行文件必须解析所有符号，否则链接失败）。因此即使未加-luv，cc -shared -o libfunc.so func.o也能成功生成共享库，只是uv_close的符号会一直处于未绑定状态。

为什么ldd显示`statically linked`？

这里的statically linked是ldd的一种易混淆输出——它并非指你的共享库是静态编译的，而是该共享库没有任何动态依赖库。由于未加-luv，链接器没有将libuv.so.1写入共享库的动态依赖列表，ldd扫描不到需要加载的外部动态库，就会输出statically linked。

两种编译方式的核心差异

未加-luv的情况：
- 生成的libfunc.so包含未定义的uv_close符号，无任何动态依赖记录。
- 当其他程序加载该共享库时，系统加载器需要在当前进程已加载的库中找到uv_close的定义，如果进程未提前加载libuv，会直接触发undefined symbol: uv_close错误。
添加-luv的情况：
- 链接时会将libuv.so.1作为依赖写入libfunc.so的动态段，ldd能识别到该依赖。
- 加载共享库时，系统会自动先加载libuv.so.1，uv_close的符号会被正确绑定，不会出现符号未定义错误。