运送libstdc .so.6与应用程序

概述我想在我的应用程序中使用 gcc 4.8.1(需要libstdc .so.6.0.18),但客户只有libstdc .so.6.0.13.我一直在使用-static-libgcc -static-stdlibc一段时间,但我的应用程序包含几个动态链接库和一个主应用程序.这意味着在编译每个动态库时,它们必须静态编译标准库,这是多余且浪费的.我想用我的产品运送我选择的标准库,但每次我在他们的环境中运行 我想在我的应用程序中使用 gcc 4.8.1(需要libstdc .so.6.0.18),但客户只有libstdc .so.6.0.13.我一直在使用-static-libgcc -static-stdlibc一段时间,但我的应用程序包含几个动态链接库和一个主应用程序.这意味着在编译每个动态库时,它们必须静态编译标准库,这是多余且浪费的.我想用我的产品运送我选择的标准库,但每次我在他们的环境中运行我的应用程序时,它总是加载错误的标准库.无论我似乎做什么,它都更喜欢/usr/lib64 /版本(它似乎优先于LD_liBRARY_PATH).

约束：

>我不允许强迫他们升级到新的标准库.
>我不想让动态库保持静态. (我可以将所有内容静态编译到主应用程序中一次,但是有一些后勤障碍阻止我将某些库重新编译为静态库).

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

当然有一个优雅的解决方案吗？

也许我的程序中只有一个错误.这是一个例子(对于审查员很抱歉,但它只是用户名的东西)：

~/example$pwd/home/username/example~/example$echo $LD_liBRARY_PATH~/example$lsMakefile  libstdc++.so.6.0.18  test.cpp~/example$makeg++ -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一直在工作……

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

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

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

总结

以上是内存溢出为你收集整理的运送libstdc .so.6与应用程序全部内容，希望文章能够帮你解决运送libstdc .so.6与应用程序所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。