问题标签 [ld]

在我下载 UnitTest++ 1.4 版（来自http://sourceforge.net/projects/unittest-cpp/）并进行制作后，我得到：

一位同事在使用相同版本的 gcc (4.2.1) 的 Mac 上没有收到此错误。（注意：我可以使用我同事构建的 libUnitTest++.a，所以我没有被阻止，但我还是想解决这个问题。）

我做了一个谷歌搜索，听起来好像ranlib已经解决了其他人的类似问题，但是 libUnitTest++.a 没有被创建，所以我不能ranlib在它上面运行。

我想用一个.interp段编译一个共享库。

我正在使用以下命令。

我最终没有 INTERP 段，就好像我从未通过该--dynamic-linker=blah选项一样。检查与readelf -l test.so。构建可执行文件时，链接器会正确处理选项并将 INTERP 段放入程序头中。如何让它也适用于共享库？

假设我有一个文件main.cpp使用. 还假设我们在同一目录中同时拥有 libmath.a 和 libmath.so。现在，如果我发出命令，Linux 的默认行为是链接到共享库。我想知道有没有办法强制程序与静态库链接而不删除或移动共享库？sin()libmathg++ -o main main.cpp -lmathlibmath.solibmath.a

我正在研究雪豹机器（10.6.5），并且正在寻找我们的 C++ 应用程序中的错误。但是，我无法使用 g++ -O0 -g 构建我们的应用程序，因为链接器崩溃：

我猜这两次崩溃是因为有两个“-arch”标志。我设法得到一个核心文件，它说崩溃发生在

有了这个提示，我从编译器标志中删除了“-g”，一切正常。此外，我们的大部分东西都可以使用“-g”构建，但只有两个大模块（.dylibs）不能，所以我没有这些的调试信息。而且，具有讽刺意味的是，这个错误就潜伏在那里，在这些 dylib 之一中。

该错误很可能是由于未初始化的内存使用造成的，因为它很少出现，并且在 valgrind 下运行应用程序会发现有一些未初始化的内存引用，但由于缺少调试信息，它只是说它发生在模块 XXX 内（ dylib 我不能用“-g”编译）

因此，我尝试从 Apple 的开源网站下载 ld 实用程序，但我发现（就像那个人一样）它不会构建，因为缺少对 Mac 特定版本的 libunwind 的依赖，Apple 不会提供离开。因此我无法重新编译链接器。

所以下一个问题是——我现在该怎么办？我真的很想避免联系 Mac 支持...

ld 版本是“ld64 97.17”，XCode 是 3.2.5，gcc 是 4.0.1。

我真的需要一些方向...

我收到了这个链接器警告：

这听起来很严重，但对我来说并不是很清楚。

有什么问题，我应该怎么做？

顺便说一句，我正在使用 Xcode 3.2.5 和 LLVM 编译器 1.6

提前致谢。

我正在尝试使用 Cocotron 在 Xcode 中为 Linux 编译。Foundation 的一切都很好，但我也在尝试使用 SDL。我已经从 Linux (Ubuntu) 复制了这些库，但我在链接时遇到了问题。

尽管也复制了 libpulse-simple （并将其放在我认为可能有意义的每个目录中），但我仍然无法删除此错误：

我正在 Linux 上构建一个 C++ 可执行文件。可执行文件链接到一些 boost 库。

这是我尝试运行二进制文件时的输出：

然后我在二进制文件上运行 ldd 以检查依赖项：

我不确定为什么找不到 liboos_system.sl.1.45.0 SO。我今天早些时候成功地建造了它。谁能解释一下？

我正在尝试更多地了解 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一个链接器脚本，该脚本隐藏除 3 之外的所有符号，这些符号在其中定义libmagic.so并由它导出。这有效......或者至少libVersion()和LIB_VERSION值匹配（并且它报告版本2而不是1）。

-- 但是，当一些数据结构被序列化到磁盘时，我注意到了一些损坏。在应用程序的目录中，如果我删除libsome1.so并在其指向的位置创建一个软链接libsome2.so，则一切都按预期工作，并且不会发生相同的损坏。

我不禁认为这可能是由于运行时链接器对符号的解析中的一些冲突引起的。我已经尝试了很多事情，比如尝试链接libsome2.so以使所有符号都指向symbol@@VER_2（我仍然对此感到困惑，因为该命令nm -CD libsome2.so仍然将符号列为symbol而不是symbol@@VER_2）......似乎没有任何作用！帮助！！！！！！

编辑：我应该在前面提到它，但有问题的应用程序是 Firefox，并且libsome1.so是libsqlite3.so随它一起提供的。我没有重新编译它们的选项。此外，使用版本脚本隐藏符号似乎是目前唯一的解决方案。那么当符号被隐藏时会发生什么呢？他们会成为 SO 的“本地人”吗？rtld 不知道它们的存在吗？当导出的函数引用隐藏符号时会发生什么？

我刚刚看到一个带有 =0 的部分定义，即

最后那个=0是什么意思，它的意义是什么？

假设我有：

• /usr/lib/libsomething.so.1在机器 A 上；
• /usr/lib/libsomething.so.2在机器 B 上。

两台机器都有/usr/lib/libsomething.so符号链接到各自的库。

如果我使用gccwith -lsomething（甚至/usr/lib/libsomething.so）链接，它将遵循符号链接，并且ldd在机器 A 上会产生如下内容：

这意味着它将无法在机器 B 上找到库。

现在我知道这些是主要的版本号更改，并且我知道它们可能不兼容，但我愿意承担这个风险。我想告诉链接器的是寻找libsomething.so，不要遵循符号链接，所以ldd会显示

在 A 但是

在 B 上。然后加载程序将遵循符号链接到那里的任何版本。

另外，我不想延迟加载 dlopen 或任何东西。我希望它在编译时链接到共享对象。

这甚至可能吗？