为什么共享库路径是可执行的硬编码? [英] Why shared library path is hardcoded in execuatble?

查看:111
本文介绍了为什么共享库路径是可执行的硬编码?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

最近我得到了一个测试二进制文件。当我使用objdump检查它时,我发现它包含硬编码的库路径。为什么需要像这样硬编码路径?不应该从SHELL环境变量或-L参数中取出路径吗?


objdump -p testprog


输出包含共享库的硬编码路径:

  .... 
NEEDED /home/test/lib/liba.so
需要/home/test/lib/libb.so
需要/home/test/lib/libc.so
...


解决方案

这三个 .so 文件在测试程序所在的主机上没有SONAME。告诉构建它的人使用 -Wl,soname,liba.so 以及类似的命令重建 liba.so 另外两个,然后重新链接主程序。


Recently I got a test binary. When I checked it using objdump, I observed that it includes hard coded library path. Why it is needed to to hardcode the path like that? Shouldn't the path be taken from SHELL environment variables or -L parameter instead ?

objdump -p testprog

The output includes the hardcoded path to shared libraries:

....
  NEEDED      /home/test/lib/liba.so
  NEEDED      /home/test/lib/libb.so
  NEEDED      /home/test/lib/libc.so
....

解决方案

This is probably because those three .so files had no SONAME on the host where your test program was built. Tell the person who built it to rebuild liba.so with -Wl,soname,liba.so and similar for the other two, then relink the main program.

这篇关于为什么共享库路径是可执行的硬编码?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆