【问题标题】:Binary linked against different shared libraries of the same package针对同一包的不同共享库链接的二进制文件
【发布时间】:2015-12-16 23:19:23
【问题描述】:

我有 2 个相互冲突的共享库,以及链接到它们的其他二进制文件。更详细地说,我有这样的事情:

  • top-lib1.solibprotobuf.so 链接;
  • top-lib2.solibprotobuf-lite.so 链接;
  • binarytop-lib1.sotop-lib2.so 链接。

问题是,当我启动我的 binary 时,由于双重释放导致的一些内存损坏而崩溃:第一个来自 protobuf.so,第二个来自 protobuf.so来自 protobuf-lite.so(参见 related bug)。

我无法访问 top-lib2.so 来源,也无法将 top-lib1.soprotobuf-lite.so 链接 由于我的应用功能。

因此我的问题是:如何处理?

由于这次崩溃,我无法同时离开,我无法将我的库 (top-lib1.so) 与 libprotobuf-lite.so 重新链接,我无法更改 top-lib2.so

有没有办法在没有来源的情况下将 top-lib2.solibprotobuf.so 重新链接?或者还有其他可能吗?

【问题讨论】:

  • 通常依赖于其他共享库的共享库根本不链接它们的依赖项。这意味着您只需要将您的可执行文件与libprotobuf.so 链接起来,它就应该可以正常工作。你能运行ldd top-lib1.soldd top-lib2.so 并告诉我们它们是否真的链接到任何一个protobuf 库吗?并向我们​​展示最终可执行文件的链接命令行。
  • @John Zwinck: ldd top-lib2.so | grep proto: libprotobuf-lite.so.9 => /usr/lib/x86_64-linux-gnu/libprotobuf-lite.so.9 (0x00007fa17d190000); ldd top-lib1.so | grep proto: libprotobuf.so.9 => /usr/lib/x86_64-linux-gnu/libprotobuf.so.9 (0x00007f9431d94000); 最终可执行文件g++ -o test test.cpp -ltop-lib2.so -ltop-lib1.soldd test | grep proto: libprotobuf.so.9 => /usr/lib/x86_64-linux-gnu/libprotobuf.so.9 (0x00007fe639b24000); libprotobuf-lite.so.9 => /usr/lib/x86_64-linux-gnu/libprotobuf-lite.so.9 (0x00007fe625b0a000)
  • 你的链接器命令行是什么?对于top-lib1.so 和可执行文件。

标签: linux shared-libraries protocol-buffers dynamic-linking


【解决方案1】:

你确实有几个选择。

您提到的上游错误指出“libprotobuf.so 拥有libprotobuf-lite.so 拥有的一切,等等”。如果确实如此,一种可能的解决方案是二进制补丁top-lib2.so.dynamic 部分以引用libprotobuf.so 而不是-lite.so。前者更短,所以只需用libprotobuf.so\0e.so 覆盖字符串libprotobuf-lite.so 即可。

如果您不想二进制补丁top-lib2.so,您还有其他选择:

  1. 您可以将所有top-lib1.so 包含目标文件所有libprotobuf.so 链接到主二进制文件中,并在其中隐藏所有libprotobuf 的符号(通过链接器脚本)。如果你这样做,top-lib2.so无法告诉除了 libprotobuf-lite.so 之外还有其他任何东西。

  2. 你可以对top-lib1.so做同样的事情——即隐藏libprotobuf在里面。

  3. 您可以将libprotobuf.so 的副本链接到-Wl,--default-symver,这会将@@libprotobuf.so 版本附加到从libprotobuf.so 导出的每个符号中,并首先避免导致问题的符号冲突。

【讨论】:

  • 问题不在于符号冲突。问题是生成的二进制调用 一些拆卸函数两次,而libprotobuf 根本无法处理这种情况。我什至不确定链接到同一个库是否有助于解决问题。不过谢谢,你回答了我的问题。
  • @avtomaton 我不相信你理解这个问题。在 separate 对象上调用拆解函数两次是可以的。在 same 对象上调用它不是。由于(全局变量)符号冲突,这两个库试图精确地 拆除 same 对象。
猜你喜欢
  • 1970-01-01
  • 2012-03-29
  • 2013-11-11
  • 1970-01-01
  • 2021-07-25
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多