dlopen linux 实例_在Linux中在libc和libdl中执行dlopen

如果

gcc编译的程序正在调用dlopen,则必须在启用-ldl选项的情况下编译它.这意味着这样的程序依赖于库libdl.so上的运行时.事实上,通过对它执行ldd,我们看到了这一行：

libdl.so.2 => /lib/x86_64-Linux-gnu/libdl.so.2

libc.so反过来使用dlopen(例如,处理libnss.so),但是没有出现在libldl.so上执行ldd：

/lib64/ld-Linux-x86-64.so.2 (0x00007f5a488e4000)

Linux-vdso.so.1 => (0x00007fff7bdfe000)

为何如此区别？

libdl只暴露了libc中已经存在的私有dl函数以及一些包装器,使得库的使用更容易一些.您可以通过查看libdl的符号表来查看此行为.

如果在libdl上使用readelf,则限制为PRIVATE符号：

readelf -s /usr/lib/x86_64-Linux-gnu/libdl.so | grep PRIVATE

13: 0000000000000000 0 OBJECT GLOBAL DEFAULT UND [email protected]_PRIVATE (7)

14: 0000000000000000 0 FUNC GLOBAL DEFAULT UND [email protected]_PRIVATE (8)

16: 0000000000000000 0 FUNC GLOBAL DEFAULT UND [email protected]_PRIVATE (8)

18: 0000000000000000 0 FUNC GLOBAL DEFAULT UND [email protected]_PRIVATE (8)

20: 0000000000000000 0 FUNC GLOBAL DEFAULT UND [email protected]_PRIVATE (7)

25: 0000000000000000 0 OBJECT GLOBAL DEFAULT UND [email protected]_PRIVATE (7)

34: 00000000002030c0 8 OBJECT GLOBAL DEFAULT 27 _dlfcn_hook@@GLIBC_PRIVATE

39: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS GLIBC_PRIVATE

您会看到所有UND条目,从GLIBC_PRIVATE列出？这些都是引用libc中的实现.

定义的libc本身的API并未声明为将dl函数实现为公开的API,但是在glibc中,libdl与libc紧密绑定,并且它公开了已知的API.在这种情况下,glibc可以使用自身内部的私有例程来完成运行时打开和使用相关的.so文件进行nss例程.