Questions tagged «dynamic-linking»

我试图了解有关Linux中库版本控制的更多信息，以及如何使它们全部正常工作。这里是上下文： -我有两个版本的动态库，它们公开了相同的一组接口，例如libsome1.so和libsome2.so。 -应用程序链接到libsome1.so。 -此应用程序用于libdl.so动态加载另一个模块，例如libmagic.so。 -现在libmagic.so链接libsome2.so。显然，在不使用链接程序脚本隐藏其中的符号的情况下libmagic.so，在运行时，所有对接口的调用libsome2.so都解析为libsome1.so。可以通过libVersion()对照宏的值检查返回的值来确认LIB_VERSION。 -所以我接下来尝试编译并链接libmagic.so一个链接描述文件，该脚本隐藏除其中定义libmagic.so和导出的3个符号以外的所有符号。这行得通...或至少libVersion()和LIB_VERSION值匹配（并且报告版本2不是1）。 -但是，当某些数据结构序列化到磁盘时，我注意到了一些损坏。在应用程序目录中，如果我删除libsome1.so并在其指向的位置创建一个软链接libsome2.so，则一切都会按预期工作，并且不会发生相同的损坏。 我忍不住认为这可能是由于运行时链接程序的符号解析中的某些冲突引起的。我尝试了很多事情，例如尝试链接，libsome2.so以便所有符号都被链接到symbol@@VER_2（我仍然感到困惑，因为该命令nm -CD libsome2.so仍将符号列为symboland而不是symbol@@VER_2）……似乎没有任何作用！！！救命！！！！！！

13 gcc  dynamic-linking  elf 

这不是重复的，因为这处理的是我在使用时注意到的特殊性/etc/ld.so.conf。 要获取动态链接程序在库中搜索的路径，请运行命令ldconfig -v | grep -v "^"$'\t' | sed "s/:$//g"。何时/etc/ld.so.conf未列出任何路径。上一条命令的输出是 /lib /usr/lib 我认为它/lib首先搜索，然后搜索/usr/lib。当添加新的路径，例如/usr/local/lib，对/etc/ld.so.conf再重拍/etc/ld.so.cache时，输出从ldconfig -v | grep -v "^"$'\t' | sed "s/:$//g"变 /usr/local/lib /lib /usr/lib 我觉得这很奇怪，因为如果我正确地搜索列出的目录的顺序是从上到下，那么在/lib和之前会搜索其他目录/usr/lib。在受信任目录之前搜索附加目录并不奇怪，但是在/lib之前搜索时/usr/lib，这很奇怪，因为/bin＆/sbin在/usr/bin＆/usr/sbinin 之后搜索PATH。 即使被列出的路径ldconfig -v | grep -Ev "^"$'\t' | sed "s/:$//g"是从底部寻找到顶部，它仍然是一个扭曲的排序，因为额外的目录会在受信任的人后，而被搜索/lib会后进行搜索/usr/lib。 那么，ld.so搜索库路径的顺序是什么？为什么/lib以前被搜索/usr/lib？如果不是，那么为什么还要搜索其他目录/lib？

13 linux  dynamic-linking 

考虑的共享对象相关性/bin/bash，其中包括/lib64/ld-linux-x86-64.so.2（动态链接器/加载器）： ldd /bin/bash linux-vdso.so.1 (0x00007fffd0887000) libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007f57a04e3000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f57a04de000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f57a031d000) /lib64/ld-linux-x86-64.so.2 (0x00007f57a0652000) 检查/lib64/ld-linux-x86-64.so.2表明它是与以下内容的符号链接/lib/x86_64-linux-gnu/ld-2.28.so： ls -la /lib64/ld-linux-x86-64.so.2 lrwxrwxrwx 1 root root 32 May 1 19:24 /lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.28.so 此外，file报告/lib/x86_64-linux-gnu/ld-2.28.so本身可以动态链接： file -L /lib64/ld-linux-x86-64.so.2 /lib64/ld-linux-x86-64.so.2: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, …

12 linux  dynamic-linking  shared-library  file-command 

我试图在运行NixOS的VM上安装当前的oracle jre。 现在发生以下情况： [michas@cc:~]$ tar xvzf jre-7u40-linux-x64.tar.gz |grep bin/java jre1.7.0_40/bin/javaws jre1.7.0_40/bin/java_vm jre1.7.0_40/bin/java [michas@cc:~]$ ls -l ./jre1.7.0_40/bin/java -rwxr-xr-x 1 michas nogroup 7750 Aug 27 09:17 ./jre1.7.0_40/bin/java [michas@cc:~]$ ./jre1.7.0_40/bin/java bash: ./jre1.7.0_40/bin/java: No such file or directory WTF？命名文件显然在那里。到底是怎么回事？ 尝试进一步分析： [michas@cc:~]$ strace ./jre1.7.0_40/bin/java execve("./jre1.7.0_40/bin/java", ["./jre1.7.0_40/bin/java"], [/* 53 vars */]) = -1 ENOENT (No such …

11 linux  binary  dynamic-linking  nixos  patchelf 

可以使用自修改代码来加速动态链接库中的函数调用吗？ 据我了解，ELF共享库使用一种间接跳转表（过程链接表或PLT）来实现库函数的延迟绑定。目的似乎是为了避免必须修改代码段中的表，同时仍允许在第一次调用时对函数位置进行延迟解析。 在加载时甚至可能在第一个函数调用时为该表动态创建代码会更快吗？ 是否能够在进程之间尽可能多地共享代码段（动态表对于进程是私有的）？是出于安全原因（可写代码不应执行 -但是JIT始终这样做，并且加载程序可以在实际启动程序之前由加载程序添加和删​​除写许可权）？ 还是这两者的结合，而每次函数调用获得的小性能提升是不值得的？

11 libraries  dynamic-linking  dynamic-loading 

如果用户在动态链接的应用程序上工作，并且系统正在升级，是否有防止应用程序损坏的保护机制？ 还是取决于应用程序？

10 upgrade  dynamic-linking 

我已经知道的： ELF可执行文件包含许多节，显然.text和.data节已加载到内存中，因为这些是程序的主要部分。但是要使程序正常工作，它需要更多信息，尤其是在动态链接时。 我感兴趣的是.plt，.got，.dynamic，.dynsym，.dynstr等部分。ELF中负责将功能链接到地址的部分。 到目前为止，据我所知，诸如.symtab和.strtab之类的内容不会加载（或不保留）在内存中。但是链接器是否使用.dynsym和.dynstr？他们留在记忆中吗？我可以从程序代码访问它们吗？ 可执行文件的任何部分都驻留在内核内存中吗？ 我对此的兴趣主要是法医，但是有关此主题的任何信息都将有所帮助。我所阅读的有关这些表和动态链接的资源比较高级，它们仅说明工作原理，而与内存中的内容无关。 让我知道我的问题是否有任何不清楚之处。

10 linux  memory  dynamic-linking  elf  dynamic-loading 

在某些情况下，某个程序将依赖于库版本xy，而另一个依赖于库版本xz，但据我所知，没有软件包管理器允许我同时安装xy和xz有时它们将同时允许两个主要版本（例如qt4和qt5，它们可以同时安装），但（似乎）绝不是次要版本。 为什么是这样？例如，阻止它的限制因素是什么？我认为一定有充分的理由不允许这种看似有用的功能。例如，在加载共享库时，没有字段指示要加载哪个版本，因此Linux无法知道如何决定加载哪个版本？还是真的没有理由吗？像所有次要版本一样，还是应该兼容的？

10 package-management  dynamic-linking  version  shared-library 

我正在寻找一种实用程序，其行为与相同which，但是要在$ LD_LIBRARY_PATH中定义的目录中查找共享库（* .so）？

9 c  dynamic-linking 

在安装更新以解决CVE-2014-0160（OpenSSL Heartbleed错误）之后，我必须小心重启可能正在使用libssl的所有内容-许多服务（例如Apache和我的VPN软件）仍然加载了旧的易受攻击的libssl ，而我的包裹管理员没有尝试纠正这一问题。 这让我开始思考：更新共享库后，如何可靠地找出当前正在运行的程序中链接了旧版本的库？我确信必须有一种方法可以在链接器级别或文件描述符级别查询正在运行的进程，以确定它们已加载的给定共享库的实例与当前磁盘上的实例是否相同。

9 upgrade  libraries  dynamic-linking 

我在nix不是root用户的系统中以“单用户模式” 使用（请参见下面有关我的nix设置的说明）。 我想快速运行我的一个二进制文件，该二进制文件与系统中不存在的库动态链接。 因此，我使用以下命令安装了该库nix： $ nix-env -qa 'gmp' gmp-4.3.2 gmp-5.1.3 $ nix-env -i gmp-5.1.3 但是链接器仍然找不到该库： $ ldd -r ../valencies ../valencies: /lib64/libc.so.6: version `GLIBC_2.15' not found (required by ../valencies) ../valencies: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ../valencies) linux-vdso.so.1 => (0x00007fffbbf28000) /usr/local/lib/libsnoopy.so (0x00007f4dcfbdc000) libgmp.so.10 => not found libffi.so.5 => /usr/lib64/libffi.so.5 (0x00007f4dcf9cc000) …

8 path  not-root-user  dynamic-linking  nix  altlinux 

我有一个简单的C程序。我跑： $ gcc Q1.c -Wall -save-temps -o Q1 然后，我检查生成的可执行文件： $ objdump -f Q1 Q1: file format elf32-i386 architecture: i386, flags 0x00000112: EXEC_P, HAS_SYMS, D_PAGED start address 0x080483b0 然后我用静态链接编译它： $ gcc Q1.c -Wall -save-temps -static -o Q1 并再次检查文件： $ objdump -f Q1 Q1: file format elf32-i386 architecture: i386, flags 0x00000112: EXEC_P, …

8 c  gcc  dynamic-linking  static-linking 

我想知道是否可以执行位于堆空间内的代码段吗？

8 linux  memory  dynamic-linking 

我注意到我编译到gcc的所有程序都链接到vdso库。这个库是否包含对内核的系统调用（如mmap（）和fork（）以及其他系统调用）的库？ 我知道系统调用不是GNU C标准库的功能，因此它们的目标代码必须位于在编译时与应用程序链接的某个库中吗？ 那么vdso是那个库吗？

4 kernel  libraries  dynamic-linking  system-calls  shared-library 

从一个单独的问题以及有关该主题的其他文章看来ld.so.conf.d，在通过/lib或提供的任何库之前，总是会解决定义的其他库路径（即，在名称冲突的情况下，例如覆盖系统库时）/usr/lib。 是否有可能通过ld.so.conf.d某种机制创建一个系统范围的路径，在该路径下可以以最低/最新的分辨率级别来解析库？例如，我希望库/ParanoidAndroid/可以被解析，但是我希望该路径成为搜索它们的最后一个位置（即，优先于存储在中的库中/lib和/usr/lib之上的库/ParanoidAndroid/），因此现在的查找顺序为： LD_LIBRARY_PATH中的目录； 来自/etc/ld.so.conf的目录； / lib; / usr / lib。 / ParanoidAndroid;

2 linux  libraries  dynamic-linking  linker  ld