Fatal编程技术网
  • linux/
  • Linux ELF—为什么正常链接运行速度比'；ldd-r'；？

Linux ELF—为什么正常链接运行速度比'；ldd-r'；？

linux linker

Linux ELF—为什么正常链接运行速度比'；ldd-r'；？,linux,linker,shared-libraries,ld,elf,Linux,Linker,Shared Libraries,Ld,Elf,我有一个exe，其中没有任何代码更改，但我担心它链接到的符号不再存在于其共享对象上。我找到了两种方法来测试这一点： 运行ldd-r 重新链接exe 在某些情况下，重新链接似乎比运行ldd-r更快，这是什么原因 在某些情况下，重新链接似乎比运行ldd-r更快，这是什么原因 考虑一个简单的例子：main.o从libfoo.so调用foo（） gcc main.o -L. -lfoo ld必须完成的工作量：发现正在调用foo，发现它是在libfoo中定义的。没有太多的工作 现在假设libfoo.

我有一个exe，其中没有任何代码更改，但我担心它链接到的符号不再存在于其共享对象上。我找到了两种方法来测试这一点：

  • 运行
    ldd-r
  • 重新链接exe
在某些情况下，重新链接似乎比运行ldd-r更快，这是什么原因

在某些情况下，重新链接似乎比运行ldd-r更快，这是什么原因

考虑一个简单的例子：
main.o
从
libfoo.so
调用
foo（）


gcc main.o -L. -lfoo



ld
必须完成的工作量：发现正在调用
foo
，发现它是在
libfoo中定义的。没有太多的工作

现在假设
libfoo.so
本身已链接到
libbar.so
，并从中调用10000000个不同的符号


ldd-r
必须做什么？它将首先在
a.out
中查找任何未解析的符号（只有一个：
foo
），然后在
libfoo.so
（简单）中找到它的定义。接下来，必须考虑<代码> LBFoO中的每个未定义的符号。所以，并且为它们找到所有的定义（在<代码> LBBAR。SO ）。这大约是100万倍的困难。对于
libbar.so
，以及链接到其中的所有其他库，重复上述操作


因此，在上述条件下，
ld
比
ldd-r
花费的时间要少得多也就不足为奇了，但是
ld
也会检查从
libfoo
到
libbar
的调用，不是吗？