Articles of ldd

修改可执行文件的链接path

ldd实用程序显示二进制可执行文件所依赖的共享目标文件,还显示文件系统上该二进制可执行文件的path。 是否有可能修改这个path,在现有的可执行文件? 例如,假设我有一个二进制“foo.so”,我说: libssl.so.0.9.8 => /opt/lib64/libssl.so.0.9.8 如果我将这个.so文件部署到指定path中没有 lbssl.so.0.9.8的机器上, 那么当使用foo.so时,我当然会得到一个链接器错误。 那么,是否可以修改现有可执行文件上的链接path? 我意识到另一个解决scheme是确保现有的链接path指向一个有效的目标文件,实际上是将目标文件复制到ldd显示的path。 但是让我们说,我有一个不可行的情况。 是否有可能修改现有的可执行文件的链接path?

确定哪些可执行文件链接到Linux上的特定共享库

如何列出链接到libssl的Red Hat Linux系统上的所有可执行文件? 我可以接近: find / -type f -perm /a+x -exec ldd {} \; | grep libssl ldd向我展示了可执行文件链接的库,但是包含库名称的行并不显示文件名,所以虽然我和grep有很多匹配,但我不知道如何退出从中发生匹配的可执行文件。 任何帮助将不胜感激。

我如何知道ldd如何解决依赖关系

对于由ldd标识的依赖项,我怎么知道它是使用二进制的RPATH还是环境的LD_LIBRARY_PATH?

对符号“dlsym @@ GLIBC_2.4”的未定义引用

首先,请记住,我是Linux新手。 编译我的项目时遇到问题。 我不断收到以下错误: / usr / bin / ld:CMakeFiles / Robot.dir / source / ModuleHandler.cpp.o:未定义引用符号'dlsym @@ GLIBC_2.4'//lib/arm-linux-gnueabihf/libdl.so.2:error添加符号:命令行中缺lessDSO collect2:ld返回1退出状态 首先关掉正确的目录是: /usr/lib/arm-linux-gnueabihf/libdl.so而不是: //lib/arm-linux-gnueabihf/libdl.so 我尝试更新我的ldconfig.conf文件,设置LD_LIBRARY_PATH ,使用ldd -r无济于事。 CMAKE用于创buildmake文件。 我以前没有编译过的问题。 它是在我进行apt-get升级的时候开始的,或者从VS尝试交叉编译之后开始的。 任何build议将不胜感激! //弥敦道

了解更多关于可执行文件的共享库

有没有办法从可执行文件知道共享库的使用? 以DivFix ++为例: $ file DivFix++ DivFix++: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped

强制二进制文件使用共享库(.so)的特定(较新)版本

我有一个较旧的二进制可执行文件(utserver,closed source),我试图在运行Fedora 22的系统上运行。 utserver需要openssl_1.0.0 – F22提供openssl_1.0.1k 我做了两个符号链接: $ sudo ln -s /usr/lib64/libssl.so.1.0.1k /usr/lib64/libssl.so.1.0.0 $ sudo ln -s /usr/lib64/libcrypto.so.1.0.1k /usr/lib64/libcrypto.so.1.0.0 但试图运行utserver抱怨库版本: $ ./utserver ./utserver: /lib64/libcrypto.so.1.0.0: version `OPENSSL_1.0.0' not found (required by ./utserver) ./utserver: /lib64/libssl.so.1.0.0: version `OPENSSL_1.0.0' not found (required by ./utserver) 好的,所以它正在寻找一个版本string。 我编辑了utserver ELF来将stringOPENSSL_1.0.0更改为OPENSSL_1.0.1,但是我得到了同样的错误(未find'OPENSSL_1.0.1') objdump和readelf都显示OPENSSL_1.0.1存在于libssl.so.1.0.1的版本区域中: $ objdump -p /lib64/libssl.so.1.0.1 | grep OPENSSL 3 0x00 0x066a2b21 OPENSSL_1.0.1 […]

为什么我的Linux应用程序拉错了.so库?

我有一个使用NetCDF C ++库的应用程序,而NetCDF正在使用HDF-4库。 然而,这是拉错了 HDF-4库。 以下是我的应用程序链接的方式: /apps1/intel/bin/icpc -gxx-name=/apps1/gcc-4.5.0/bin/g++ -shared -o lib/libMyCustom.so -Llib -L/apps1/boost-1.48.0/lib -Wl,-rpath=/apps1/boost-1.48.0/lib -L/apps1/gdal-1.8.0-jasper/lib -Wl,-rpath=/apps1/gdal-1.8.0-jasper/lib -L/new_apps1/hdf4/lib -Wl,-rpath=/new_apps1/hdf4/lib -L/new_apps1/netcdf/lib -Wl,-rpath=/new_apps1/netcdf/lib -lboost_system -lboost_serialization -lboost_date_time -lboost_thread -lgdal -ldf -lmfhdf -lnetcdf_c++ MyProj/obj/ProjUtility.o MyProj/obj/ProjMetadataException.o MyProj/obj/ProjTimestampUtil.o 我已经设置了我的LD_LIBRARY_PATH很短: LD_LIBRARY_PATH=/new_apps1/hdf4/lib:/new_apps1/hdf5/lib: /apps1/intel/composerxe/lib/intel64:/apps1/gcc-4.5.0/lib64:/apps1/gcc-4.5.0/lib 这里是从ldd -v输出摘录: libdf.so.0 => /new_apps1/hdf4/lib/libdf.so.0 (0x00002af5baabc000) libmfhdf.so.0 => /new_apps1/hdf4/lib/libmfhdf.so.0 (0x00002af5bad61000) libnetcdf_c++.so.5 => /new_apps1/netcdf/lib/libnetcdf_c++.so.5 (0x00002af5baf85000) libhdf5.so.6 => /new_apps1/hdf5/lib/libhdf5.so.6 (0x00002af5bd1e7000) libgif.so.4 => /usr/lib64/libgif.so.4 […]

用ldd -u,输出是“Unused direct dependencies:/lib64/libc.so.6”,但是我真的用printf()

在Fedora 18中,我写了一个文件“ac”,如下所示: #include <stdio.h> void main(void) { printf("a"); } 然后用gcc 4.7.2编译: gcc ac -oa 最后用ldd 2.16: ldd -u ./a 输出是如此奇怪: Unused direct dependencies: /lib64/libc.so.6 由于printf()我认为这个目标文件真的使用/lib64/libc.so.6 。 在Red Hat 6中, 没有这个奇怪的外表。

如何在Linux上的/etc/ld.so.conf中获取path列表

通过/etc/ld.so.confconfiguration的path列表以及包含的文件,获取path列表的最方便可靠的方法是什么? 手动parsing文件似乎不是一个好主意 – 格式可能会在将来的修订中改变。 为了更好地理解这个问题,我会在下面给你具体的细节。 请注意,尽pipe有这些细节,但这是一个普遍的编程问题,适用于其他情况。 有一个叫做LuaRocks的程序。 它是Lua编程语言的包pipe理器(有点像Ruby的gem或Python的蛋)。 LuaRocks包裹被称为“岩石”。 作为一个方便的function,LuaRocks允许一个摇滚作者指定一个摇滚的外部依赖列表,制定为C头文件和/或dynamic库文件列表。 (.so在Linux上。)如果指定的文件不存在,则无法安装Rock。 目前,在Linux上,LuaRocks默认通过在两个硬编码path/usr/lib和/usr/local/libsearch文件来检查.so文件存在。 我相信这是不正确的行为,这是Ubuntu和其他Debian发行版中最近的变化所打破的。 更新:path本身不是硬编码的,但是在configuration文件中是用户可configuration的。 国际海事组织并不是最好的解决办法。 相反(据我所知),LuaRocks应该在由/etc/ld.so.conf指定的path和它包含的文件中查找文件。 (现在请重新阅读上面的问题;-))

ld64.so存在于ldd中,在运行时丢失

我正在编译一些代码,出于各种原因,我正在静态地做。 在我的Ubuntu 12.04 / gcc 4.6.3机器上编译执行得很好,完全是静态的: > ldd mycode not a dynamic executable 到现在为止还挺好。 但是我也需要在另一台运行gcc 4.5.3的科学Linux 5系统的机器上运行它。 出于某种原因,ldd还剩下一些dynamic库: > ldd mycode linux-vdso.so.1 => (0x00007fffd75fd000) libstdc++.so.6 => /usr/local/swift/gcc-4.5.3/lib64/libstdc++.so.6 (0x00002b4bafab2000) libm.so.6 => /lib64/libm.so.6 (0x000000398ca00000) libc.so.6 => /lib64/libc.so.6 (0x000000398c600000) /lib/ld64.so.1 => /lib64/ld-linux-x86-64.so.2 (0x000000398c200000) libgcc_s.so.1 => /usr/local/swift/gcc-4.5.3/lib64/libgcc_s.so.1 (0x00002b4bafdb8000) 这本身就很好。 代码编译并链接OK,正如您从ldd中所看到的,所有依赖关系都已解决。 但是,当我试图在SL机器上执行它时,它会失败: > ./mycode /lib/ld64.so.1: bad ELF interpreter: No such […]