为何共享库libfunc.so未生成预期的libuv.so依赖？

我尝试创建依赖共享库libuv.so的共享库libfunc.so，期望执行ldd libfunc.so时能看到该依赖关系。

代码实现 #

#include <uv.h>

int func() {
  uv_timespec64_t now;

  uv_clock_gettime(UV_CLOCK_REALTIME, &now);

  return 0;
}

编译命令及环境 #

$ cc --version && cc -fpic -ggdb -Wall -c -o func.o func.c
cc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ cc -shared -o libfunc.so func.o -fpic -ggdb -Wall -luv

异常现象 #

执行ldd未显示libuv.so依赖：

$ ldd ./libfunc.so
        linux-vdso.so.1 (0x00007fff827ae000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f14b291e000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f14b2b54000)

通过nm命令可看到libfunc.so中存在未定义符号uv_clock_gettime，但在代码中添加uv_close(NULL, NULL)调用后，ldd即可显示libuv.so依赖。后续测试-O0编译、打印变量值等方式仍无法生成依赖；使用链接器--no-as-needed标志可强制添加依赖。

请问为何仅调用uv_clock_gettime时不会生成libuv.so依赖，如何解决该问题？

1. 链接器默认行为限制：GNU链接器默认启用--as-needed选项，该选项会在链接共享库时，仅当指定的库实际提供了当前目标文件中未定义的符号时，才会将该库添加到输出共享库的依赖（NEEDED）列表中。
2. 符号匹配异常：虽然代码中调用了uv_clock_gettime，但链接器检查libuv.so时，发现该库并未提供这个符号——可能是libuv头文件与库文件版本不匹配（头文件有声明但库未实现），或该函数是弱符号/inline函数导致链接逻辑无法识别。
3. uv_close的触发作用：当添加uv_close调用时，libuv.so明确提供了这个强符号，链接器因此将libuv.so加入依赖列表；此时即使uv_clock_gettime仍为未定义符号，运行时也会通过已添加的libuv.so去解析。

1. 强制添加依赖（最直接） #

在链接命令中添加-Wl,--no-as-needed选项，关闭--as-needed的自动优化，强制链接器将libuv.so加入依赖列表：

cc -shared -o libfunc.so func.o -Wl,--no-as-needed -luv -Wl,--as-needed

（末尾的-Wl,--as-needed用于恢复默认行为，避免影响其他库的链接优化）

2. 确认libuv版本与符号存在性 #

检查libuv.so中是否存在uv_clock_gettime符号：

nm -D /usr/lib/x86_64-linux-gnu/libuv.so | grep uv_clock_gettime

如果无输出，说明该符号不存在，需更新libuv版本或重新编译libuv并启用相关功能，确保头文件与库文件版本一致。

3. 确保链接顺序正确 #

始终将-luv放在所有依赖它的目标文件之后（你的当前编译命令已符合此要求），链接器会从左到右处理目标文件与库，优先解决左侧目标文件的未定义符号。

4. 添加强符号引用 #

在代码中添加对libuv中明确存在的强符号的调用（如uv_close），让链接器识别到需要依赖libuv.so，间接解决uv_clock_gettime的符号解析问题。

内容的提问来源于stack exchange，提问作者StoneThrow