【问题标题】:Shipping libstdc++.so.6 with application随应用程序一起发送 libstdc++.so.6
【发布时间】:2014-12-09 18:18:26
【问题描述】:

我想为我的应用程序使用 gcc 4.8.1(需要 libstdc++.so.6.0.18),但是客户只有 libstdc++.so.6.0.13。我已经使用-static-libgcc -static-stdlibc++ 有一段时间了,但我的应用程序由几个动态链接库和一个主应用程序组成。这意味着在编译每一个动态库时,都必须静态编译标准库,这样既多余又浪费。我只想将我选择的标准库与我的产品一起发布,但是每次我在像他们这样的环境中运行我的应用程序时,它总是加载错误的标准库。无论我做什么,它都更喜欢/usr/lib64/ 版本(它似乎优先于LD_LIBRARY_PATH)。

约束:

  1. 我不能强迫他们升级到新的标准库。

  2. 我不想将动态库设为静态。 (我可以一次将所有内容静态编译到主应用程序中,但有一些后勤障碍阻止我将某些库重新编译为静态库)。

-Wl,-rpath=$(path_to_directory) 有点危险,但它是合法的,因为客户确实提供了一些允许我设置路径变量的设置。但是,设置我的新 stdlibc++ 的 rpath 似乎并没有覆盖默认的 /usr/lib64 版本。我仍然收到GLIBCXX 错误,因为它不会使用正确的库。

肯定有一个优雅的解决方案吗?

也许我的程序中只是一个错误。这是一个例子(对审查员感到抱歉,但这只是用户名的东西):

~/example$ pwd
/home/username/example
~/example$ echo $LD_LIBRARY_PATH

~/example$ ls
Makefile  libstdc++.so.6.0.18  test.cpp
~/example$ make
g++ -std=c++11 -Wall -Werror test.cpp -o test
~/example$ ldd test
./test: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by ./test)
    linux-vdso.so.1 =>  (0x00007fffe5919000)
    libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x000000390b800000)
    libm.so.6 => /lib64/libm.so.6 (0x0000003904800000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x000000390b400000)
    libc.so.6 => /lib64/libc.so.6 (0x0000003904400000)
    /lib64/ld-linux-x86-64.so.2 (0x0000003904000000)
~/example$ setenv LD_LIBRARY_PATH /home/username/example
~/example$ echo $LD_LIBRARY_PATH
/home/username/example
~/example$ ldd test
./test: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by ./test)
    linux-vdso.so.1 =>  (0x00007fff2d3ff000)
    libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x000000390b800000)
    libm.so.6 => /lib64/libm.so.6 (0x0000003904800000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x000000390b400000)
    libc.so.6 => /lib64/libc.so.6 (0x0000003904400000)
    /lib64/ld-linux-x86-64.so.2 (0x0000003904000000)

对不起,我犯了一个相当愚蠢的错误......

~/example$ file libstdc++.so.6.0.18 
libstdc++.so.6.0.18: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped

一些 dweeb 构建了错误版本的库,另一个 dweeb(即我自己)尝试在 64 位机器上使用它。一直在使用LD_LIBRARY_PATH...

【问题讨论】:

  • 我希望 LD_LIBRARY_PATH 能够工作:您是否尝试过 ldding 设置和不设置 LD_LIBRARY_PATH 的二进制文件?还要记住,LD_LIBRARY_PATH 永远不会在海拔高度上持续存在。
  • 显示您如何设置 LD_LIBRARY_PATH,以及ldd $x | fgrep ++ 的输出,其中$x 涵盖您发布的所有二进制文件,设置了 LD_LIBRARY_PATH 和/或-Wl,-rpath= 生效。
  • 好的,所以LD_LIBRARY_PATH 应该优先?我的应用程序在用户模式下运行,因此没有提升的权限。我基本上是这样做的:使用 gcc 4.8.1 编译(其配置解析与正确库的链接),设置setenv LD_LIBRARY_PATH /home/myusername/:${LD_LIBRARY_PATH},然后尝试运行/ldd 程序。在这个例子中我想要的标准库在我的主目录中。这应该优先于系统路径?
  • 你能试试export LD_LIBRARY_PATH=/home/username/example,因为我认为setenv只是把它当作一个shell变量。
  • 我在 cshell,可悲的是客户也是。

标签: c++ linker libstdc++


【解决方案1】:

您的问题是可执行文件链接到 soname libstdc++.so.6 而不是完整库文件名 libstdc++.so.6.0.16。动态链接器将在通常的位置(即 LD_LIBRARY_PATH、DT_RPATH、ldconfig 目录等)查找 libstdc++.so.6,因此要确保找到 6.0.18 版本,您需要一个名为 libstdc++.so.6 的符号链接指向它。

而不是使用 LD_LIBRARY_PATH(它在您无法控制的机器上很脆弱,因为用户可能会改变他们的环境)我更喜欢使用 '-Wl,-rpath,$ORIGIN' 链接(注意,引号是阻止 shell 扩展 $ORIGIN 所必需的)

$ORIGIN 的 RPATH 告诉动态链接器开始在与可执行文件相同的目录中查找共享库,因此如果您将 libstdc++.so 与可执行文件一起发布,它将被找到。如果您想在 bin 目录中发布可执行文件并将库放在 lib 目录中,您可以使用 '-Wl,-rpath,$ORIGIN/../lib' 或其他相对于可执行文件位置的路径。

【讨论】:

  • 啊,我以前见过那个 ORIGIN 的东西,但我没有意识到它是链接器的关键字;我以为它只是一个常用的shell变量(这完全会适得其反)。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2021-10-25
  • 1970-01-01
  • 1970-01-01
  • 2017-11-30
  • 2019-05-04
  • 1970-01-01
相关资源
最近更新 更多