Questions tagged «dynamic-linking»

在计算中,动态链接是指操作系统(OS)加载(从持久性存储复制到RAM)并链接(填充跳转表并重新定位指针)可执行文件在运行时所需的共享库的过程,也就是说,在执行时。

4
SO(共享对象)编号如何工作?
我知道Linux下的共享库使用“ so数字”,即共享库的不同版本具有不同的扩展名,例如: example.so.1 example.so.2 我的想法是要有两个不同的文件,以便在系统上可以存在一个库的两个版本(与Windows上的“ DLL Hell”相对)。我想知道这在实际中如何运作?通常情况下,我看到example.so其实是一个符号链接到example.so.2这里.2是最新版本。然后,如何根据旧版本的应用程序example.so正确识别它?关于必须使用什么数字有任何规定吗?还是这仅仅是约定?是否与Windows在系统之间传输软件二进制文件的情况不同,如果系统具有共享对象的较新版本,则从源代码进行编译时会自动链接到较旧的版本? 我怀疑这是有关的,ldconfig但我不确定如何。


2
在64位系统上运行32位二进制文​​件时收到“找不到”消息
我目前在debian(wheezy / amd64)上遇到一个奇怪的问题。 我已经创建了一个chroot来安装服务器(抱歉,我无法提供更多详细信息)。我们称之为路径/chr_path/。为了使事情变得容易,我已经用debootstrap(也是wheezy / amd64)初始化了此chroot。 chroot内的所有文件似乎都可以正常工作,但是当我启动服务器的安装程序脚本时,我得到了:( zsh: Not found /some_path/perl由于某些原因,安装程序包含perl二进制文件) 自然,我检查了/some_path/位置并找到了“ perl”二进制文件。file在chroot环境中返回: /some_path/perl ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped 该文件存在,看起来不错,具有正确的权限。我可以使用file,ls,vim它但只要我努力去执行它- ./perl例如-我得到:zsh: Not found ./perl。 这种情况对我来说是可以理解的。此外: 我可以在chroot中执行其他基本二进制文件(/ bin / ls,...) 对于项目随附的其他二进制文件,我也有同样的问题 当我尝试从主根目录(/chr_path/some_path/perl)执行二进制文件时,它可以工作。 我尝试将其中一个二进制文件与我的文件副本放在一起ls。我检查了访问权限是否相同,但这并没有改变任何内容(一个正在工作,另一个则没有)



3
查找在实时系统上定义的共享库符号在哪里/列出系统上导出的所有符号
基本上,这是两个问题合而为一-因为如果我可以列出系统中导出的所有符号以及它们的共享库路径,那么我可以简单地grep输出该内容。 对于内核符号,我想它会更容易-因为我们可以始终cat /proc/kallsyms获取加载到内存中的那些模块的所有符号的列表;然后sudo cat /proc/modules会提供已加载模块及其地址的列表,但不会给出模块从其加载的路径(如果它们是作为单独的树外.ko对象构建的) 例如,我尝试kst使用ltrace以下方法跟踪程序: $ ltrace kst2 ... _ZNK13QGraphicsItem10parentItemEv(0xa1ccdb4, 0, 0xbfe631a8, 0x823652b, 0xbfe63298) = 0xa1ce854 __dynamic_cast(0xa1ce854, 0x839ff00, 0x8306b80, 84, 0xbfe63298) = 0xa1ce800 _ZNK13QGraphicsItem10parentItemEv(0xa1ccdb4, 0x839ff00, 0x8306b80, 84, 0xbfe63298) = 0xa1ce854 __dynamic_cast(0xa1ce854, 0x839ff00, 0x8306b80, 84, 0xbfe63298) = 0xa1ce800 ... ...,我想知道它在哪里_ZNK13QGraphicsItem10parentItemEv。 那么,如何处理共享库符号?阅读[gcc-help] Re:查找定义了符号的库。; 我尝试过这样的事情: $ find /usr/lib -name '*.so*' -exec nm …

4
即使文件存在并且在PATH中,Linux可执行文件也会失败并显示“找不到文件”
我想启动wine可执行文件(版本2.12),但是出现以下错误($= shell提示符): $ wine bash: /usr/bin/wine: No such file or directory $ /usr/bin/wine bash: /usr/bin/wine: No such file or directory $ cd /usr/bin $ ./wine bash: ./wine: No such file or directory 但是,文件在那里: $ which wine /usr/bin/wine 可执行文件肯定在那里,并且没有死的符号链接: $ stat /usr/bin/wine File: /usr/bin/wine Size: 9712 Blocks: 24 IO Block: 4096 …

2
如何在不崩溃的情况下升级共享库?
在这里它说您可以重写可执行文件,并且该进程将正常运行-进程重新启动时将重新读取该文件。 但是,当我尝试在进程运行时替换二进制文件时(使用scp,从开发人员到测试服务器),它说“文件繁忙”。而且,如果我替换了共享库文件(* .so),则链接该文件的所有进程都会崩溃。 为什么这样?我想念什么吗?如何在不停止/不破坏进程的情况下替换二进制文件?

1
为什么Unix / Linux系统不遍历目录,直到找到所需的链接库版本?
我有一个名为“ alpha”的二进制可执行文件,它需要一个链接库(libz.so.1.2.7),该库位于 /home/username/myproduct/lib/libz.so.1.2.7 我通过执行以下命令在生成二进制可执行文件之前将其导出到终端实例。 export LD_LIBRARY_PATH=/home/username/myproduct/lib/:$LD_LIBRARY_PATH 现在,当我生成另一个需要相同库但版本不同的应用程序“ bravo”时,即(libz.so.1.2.8)(可在中使用) /lib/x86_64-linux-gnu/libz.so.1.2.8,系统抛出以下错误。 version `ZLIB_1.2.3.3' not found (required by /usr/lib/x86_64-linux-gnu/libxml2.so.2) 如果我未设置LD_LIBRARY_PATH,则“ bravo”启动正常。我了解上述行为是因为LD_LIBRARY_PATH在/etc/ld.so.conf查找链接库时优先于在其中定义的目录路径,因此发生了上述错误。我只是很好奇一个为什么UNIX / LINUX的开发人员没有设计OS以便如果库的第一个实例是不同版本的情况下就根据层次结构在其他目录中搜索链接的库。 简而言之,UNIX / LINUX系统遍历一组目录,直到找到所需的库为止。但是,为什么在找到期望的版本而不是接受库的第一个实例而不考虑其版本之前,它不做同样的事情?

9
在Debian上启动Java的问题:“加载共享库时出错:libjli.so”
我正在尝试启动Java: $ java -version java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory $ ldd /usr/lib/jvm/java-6-openjdk/jre/bin/java linux-gate.so.1 => (0xb779f000) libz.so.1 => /usr/lib/libz.so.1 (0xb7780000) libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7767000) libjli.so => /usr/lib/jvm/java-6-openjdk/jre/bin/../lib/i386/jli/libjli.so (0xb7762000) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb775e000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7603000) /lib/ld-linux.so.2 (0xb77a0000 $ …

1
在debian / ubuntu中同时安装两个glibc
是否可以在同一台计算机上安装和使用两个不同的glibc版本。哪一个版本仅用于运行依赖于旧glibc二进制文件的旧版软件? 是否有可能借助程序包管理器(例如将“安装此程序包及其依赖项安装到”之类的东西/opt/old-glibc)来完成,而不是直接管理它

3
找出库是否在路径中
假设我要测试某个程序是否安装了库并且可以使用它。我可以使用ldconfig -p | grep mylib它来确定它是否已安装在系统上。但是如果仅通过设置知道该库LD_LIBRARY_PATH怎么办? 在这种情况下,程序可能能够找到该库,但ldconfig找不到。如何检查库是否在组合链接器路径中? 我要补充一点是,我正在寻找一个即使我手头上没有真正的程序(例如,该程序尚未编译)也可以使用的解决方案,我只想知道某个库存在于ld“的路径。


2
我可以使用自己的ld.so.cache吗?
ldconfig 有两个有趣的选项: -f conf Use conf instead of /etc/ld.so.conf. -C cache Use cache instead of /etc/ld.so.cache. 我尝试复制/etc/ld.so.conf到自己的主目录,并对其进行了编辑,以包括本地库/home/syockit/local/usr/lib等的路径,然后运行 ldconfig -f /home/syockit/ld.so.conf -C /home/syockit/ld.so.cache 然后,为了确认库是否已缓存,我运行了 ldconfig -f /home/syockit/ld.so.conf -C /home/syockit/ld.so.cache -p | less 它不仅包括我的所有库,还包括系统库。 现在,我想让默认链接器使用这两个。但是在man ld.so我看来,没有提到能够使用custom .conf或.cache。那么,以上两种选择的意义ldconfig何在?

1
对ld-linux.so黑客使用替代libc;更清洁的方法?
我有一个带有非常老的glibc的遗留系统,如果不进行大量测试/验证工作,就无法升级。 我现在需要多次在该系统上运行较新的程序(例如Java 1.7)。我选择了chroot解决方案,其中打包了所有需要的库,并在chroot中运行服务。 chroot的限制非常大,我宁愿尝试使用LD_LIBRARY_PATH解决问题。不幸的是,我libc.so.6: cannot handle TLS data在尝试时遇到错误。 事实证明,我也需要/lib/ld-linux.so.2chroot的。这有效: LD_LIBRARY_PATH=/home/chroot/lib /home/chroot/lib/ld-linux.so.2 /home/chroot/bin/program 但是,java通过检查/proc/self/cmdline以确定从何处加载其库来挫败我的窍门,如果二进制文件未命名为“ bin / java”,该方法将失败。Java在启动过程中也会执行自身,这使事情变得更加复杂。 在最后努力,使这项工作,我打开了Java二进制,十六进制编辑器和替换字符串/lib/ld-linux.so.2用/home/chroot/ld.so(并作出一个符号链接ld-linux.so.2),和它的工作! 但是我想每个人都会同意,将每个新二进制文件的路径重写为嵌套系统的绝对路径是一个巨大的麻烦。 有谁知道使用自定义库路径(包括自定义ld-linux.so)的更简洁方法?

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.