问题标签 [ldd]

I have a Qt executable file. When this program runs on a Ubuntu 11.04 virtual machine, the GUI is ugly though you can still tell it is the GUI that you want. When it runs on Ubuntu 12.04 of my laptop, however, everything goes well. Thus I guess there might be something wrong with the environment of the virtual machine.

To find out whether the problem lies in the libraries, I ran the command

I got library dependencies as following:

Then I am wondering how can they be different? Can I find out what is wrong by tools such as strace?

我有一个关于在多个目录下使用非标准命名约定链接共享库的问题。我需要生成的可执行文件在可执行文件当前位置搜索共享库，但找不到命令行参数来强制执行此行为。

为了演示这种行为，只需要一个目录下的共享库。

可执行文件main给出以下 ldd 输出：

我需要的输出是：

如果库按惯例命名为libmylib.so而不是mylib.so，则可以创建此输出，如下所示：

这也会根据需要删除 ldd 列表中的路径some/dir。

我已经调查了 rpath 的使用，以及 ld 和 gcc 的命令行选项，但我无法找到令人满意的解决方案。在这种情况下，不能轻易更改非标准名称和目录结构的严格要求。

我的问题是如何通过 gcc 命令行选项强制库的依赖关系相对于当前目录，而不是像第二个 ldd 中那样绝对。

谢谢你的时间，我希望我已经合理地解释了这个问题。

乔恩。

我们可以使用 ldd 来确定依赖关系，例如：

由于“日期”依赖于“libc.so”，我假设“日期”调用“libc.so”中的某个函数，并且我们知道 ldd 可以从可执行文件的 .dynamic 部分确定“日期”的 lib 依赖关系，但我的问题是编译器/链接器如何知道应该将什么写入 .dynamic 部分？更加具体：

1. 如果“libc.so”与“date”静态链接，那么这个函数的代码应该已经编译成“date”，所以在这种情况下“date”不应该依赖“libc.so”，应该没有.dynamic 部分中的“libc.so”。

2. 如果“libc.so”与“date”动态链接，在这种情况下，我假设一些代码是这样的：

句柄 = dlopen("libc.so", ..);

应该存在于 "date" 中以加载 "libc.so"，并且 "dlopen("libc.so")" 应该是 "date" 依赖于 "libc.so" 的唯一线索，在这种情况下，编译器/链接器知道“日期”取决于“libc.so”吗？它是否解析所有“dlopen”行以提取 lib 依赖关系？我认为这不是一个好方法，但真的，这是真的吗？

或者编译器/链接器是否有其他方法来确定动态链接情况下的 lib 依赖性？谢谢。

我有一个二进制文件，其中 ldd 显示了意外的依赖项和 libicuuc（来自“icu”）。

由于在这个系统上，libxml 动态依赖于 libicuuc，所以 ldd 最终找到它是有道理的，但是否期望 libicuuc 也出现在 A 的 ldd 输出中？是否有一些命令仅检索作为依赖项的依赖项链接的库？

我有一个 libTest.so 无法在某些设备上加载。logcat 绝对没用。使用arm-linux-androideabi-readelf.exe -d libTest.so我能够看到 libTest.so 需要的所有必需库。我将它们全部拉入本地 PC 上的同一个文件夹中。

如何找出缺少哪些符号以及在哪个库中？我只有 NDK 的标准工具集（nm、readelf、objdump 等）。我可以使用哪个工具以及如何使用它来解析我的 libTest.so 和所有依赖库，并告诉我哪个符号阻止我的库加载到目标设备上。

在 Fedora 18 中，我编写了一个文件“ac”，如下所示：

然后我用 gcc 4.7.2 编译它：gcc a.c -o a
最后使用 ldd 2.16：ldd -u ./a
输出太奇怪了：

Unused direct dependencies:
/lib64/libc.so.6

我认为目标文件真正使用/lib64/libc.so.6是因为printf(). 而在 Red Hat 6 中，
就没有这种奇怪的外观了。

我正在使用以下makefile

当我在上面构建它时，我ubuntu看不到myproduct. ldd但我在做同样的RHEL事情myproductldd

我的共享库即product_bridge.so建立在RHEL

在 Linux 上，我有一个使用 dlopen() 加载一些共享库的 C++ 应用程序，但我怀疑正在加载的共享库的版本不是我期望的版本，因为我的调试跟踪代码似乎不是执行。

有没有办法检查正在运行的进程以查询它当前打开的所有共享库以及每个库的路径？换句话说，类似于ldd但它适用于正在运行的可执行文件并列出运行时加载的库。

我在另一个库libmsg中使用了一个名为liblogger的日志库（我已经实现了） 。对于他们两个，我都在使用自动工具。我在我的系统中成功安装了 liblogger 库，位于 /usr/local/lib 目录下。

在另一个libmsg的 configure.ac 脚本中，我验证 liblogger 已安装在系统中，如下所示：

并将“-L/usr/local/lib”路径添加到 LDFLAGS 变量。

AC_CHECK_LIB 测试找到该库，并且libmsg库及其使用的 check_PROGRAMS 均已成功编译。

但是，当我尝试执行测试程序时，出现错误：

加载共享库时出错：liblogger.so.0：无法打开共享对象文件：没有这样的文件或目录

实际上，ldd也找不到该库：

但图书馆实际上就在那里，在/usr/local/lib。

为了链接测试程序，使用以下指令调用 libtool：

这实际上与以下内容相呼应：

所以，-llogger标志被-L[..] /usr/local/liblogger.so取代（我想这是一个正确的行为？我还不能确定它......）

实际上，如果我用以下方式调用测试程序：

LDPRELOAD=/usr/local/lib/liblogger.so 消息

它确实有效。

谁能告诉我我错过了什么？

在 Linux ldd 中有非常有用的选项 LD_DEBUG。

LD_DEBUG (glibc since 2.1) 输出关于动态链接器的详细调试信息。如果设置为 all，则打印它拥有的所有调试信息，如果设置为 help，则打印一条帮助消息，说明可以在此环境变量中指定哪些类别。从 glibc 2.3.4 开始，对于 set-user-ID/set-group-ID 二进制文件，LD_DEBUG 被忽略。

我可以在 FreeBSD 上做吗？