标签: libstdc++

我想在前面加上一个重要的通知,我不是一个C/C++程序员,并且很少知道库的链接如何在C中工作.

我们的代码使用libstdc ++.so.6(gcc 3.4,我认为).我们有第三方预编译(闭源)库使用libstdc ++.so.5(gcc 2.something或3.2,我认为).这是在Linux上.我们有第三方库的.a和.so版本.

是否可以使用第三方库构建我们的应用程序？怎么样？是否有可能在没有libstdc ++的情况下构建/运行我们的应用程序.so.5安装了我们的机器,怎么样？

如果我忘记了一些重要信息,请告诉我 - 我几乎不知道这些东西是什么.我意识到完全答案可能是不可能的; 我真的在寻找方向和指导.静态链接,动态,重建,预建某某,切换到版本x,或者符号链接quizdoodle等.

更新:

我们尝试使用dlopenwith RTLD_LOCAL将第三方库与我们应用程序的其余部分隔离开来.这似乎大部分都有效,但是,由于未知原因,我们留下了大量内存泄漏.我们怀疑,当我们调用时dlopen,第三方库会malloc从已经加载的.so.6中提取符号,并且事情变得混乱.

对于咯咯笑,我们尝试将第三方库放入LD_PRELOAD,然后运行我们的应用程序,内存泄漏似乎完全消失.

为了使用C++ 11和c ++ 14的功能,我有一个使用较新版本的gcc(4.9.1)编译的应用程序,因此是一个较新版本的libstdc ++.该应用程序由许多小程序组成,因此我将libstdc ++作为共享库而不是静态库链接(即我不希望使用-static-libstdc ++)

我希望使用/ opt // lib64下的应用程序发布新版本的libstdc ++(注意:这是在GPL例外情况下特别允许的)

新版本的libstdc ++.so与目标平台上的版本只有次要版本不同.libstdc ++旨在向前兼容,以便现有程序可以使用新版本的库.但是,当一些程序使用新版本而不是旧版本时,我观察到行为(即错误)的细微差别.我希望防止这种情况发生.

我还发现,ld将尝试我的应用程序使用的libstdc系统版本链接++,除非我把的/ opt // lib64的较早的LD_LIBRARY_PATH.据说你可以使用强制链接特定版本-l:<library>.<version>,但是,这似乎不起作用.我怀疑它会用于用户创建的库,但不会用于像libstd ++这样的语言运行库,因为gcc本身会生成链接器脚本.同样在我的一个目标平台(RHEL5)上,gcc/ld甚至都不理解它.我认为这可以通过使用-nostdlib并在我的构建系统中链接所需的所有内容(例如-lgcc),而不是将它留给我更喜欢的gcc.到目前为止我还没试过这个.

解决此问题的一种简单方法是确保LD_LIBRARY_PATH在运行我的应用程序时包含/ opt // lib64,否则或者我可以将LD_PRELOAD与正确的库版本一起使用.如果有人决定忽略我的建议和运行,这个问题

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/<vendor>/lib64 

它可能会导致细微而难以诊断的问题.所以我一直在寻找更好的方法.

我想知道是否有某种方法我可以将libstdc ++重命名为lib_stdc ++并链接到该soname.重命名libstdc ++是不够的,因为您需要更改readelf给出的文件中的soname.即

0x000000000000000e (SONAME)             Library soname: [libstdc++.so.6]

如果你在一个正常的程序上执行此操作,gcc即使使用-l:stdc++.so.6.0.20说,你会发现这给出了主要版本,而不是特定的次要版本.即

readelf -d <myapp>
0x0000000e (SONAME)                     Library soname: [libstdc++.so.6]

而不是:

0x0000000e (SONAME)                     Library soname: [libstdc++.so.6.0.20]

所以我改为使用我想要依赖的soname创建一个虚拟共享库,以便添加依赖项,如下所示:

gcc dummy.o -Wl,-soname,lib<vendor>_stdc++.so.6.0.20 -nostdlib -shared -o lib<vender>_dummycpp.so

(其中dummy.o是一个空的目标文件,由空的源文件制成,用于停止-nostdlib导致投诉)

然后:

gcc <myapp> -l<vendor>_dummycpp

根据需要,我现在得到:

readelf -d <myapp>

0x0000000000000001 (NEEDED)             Shared library: …

我正在尝试加载使用SWIG创建的PHP扩展,但是在启动PHP时出现以下错误:

PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib/php5/20090626/libtg.so' - /usr/lib/php5/20090626/libtg.so: undefined symbol: __gxx_personality_v0 in Unknown on line 0

我试图加载的扩展名是命名的libtg.so,并使用以下命令编译:

g++ -shared libtg_wrap.o -o libtg.so

其中libtg_wrap.o是SWIG生成的包装器代码的目标文件.

__gxx_personality_v0可以找到缺少的符号libstdc++.so,如以下命令所示:

$ nm -D /usr/lib/libstdc++.so.6 | grep __gxx_personality_v0
00000000000b9990 T __gxx_personality_v0

libstdc++.solibtg.so在以下命令中可以参考:

$ ldd libtg.so
linux-vdso.so.1 =>  (0x00007fff5f932000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f3fc937c000)
libm.so.6 => /lib/libm.so.6 (0x00007f3fc90f9000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f3fc8ee2000)
libc.so.6 => /lib/libc.so.6 (0x00007f3fc8b5f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3fc98fc000)

所以我不明白为什么它找不到符号.关于如何进一步调试这个的任何想法？

这个问题的答案如何使用clang ++/libc ++编译/链接Boost？陈述Boost与clang++和libc++,以下应该做:

./b2 clean
./b2 toolset=clang cxxflags="-stdlib=libc++" linkflags="-stdlib=libc++"

我在Scientific Linux 6.4 x86_64主机上测试了上述提示,它"主要"用于构建完整的Boost 1_53_0发行版,使用clang++ 3.3sv和libc++ 3.3svn.我大多说,因为我真的想删除所有的libstdc++依赖.

不过,以下内容:

• libboost_graph
• libboost_locale
• libboost_regex

仍显示libstdc++依赖关系(ldd输出使其非常明显).我想知道一个很好的方法来删除这样的,并会欣赏任何提示.

我正在尝试使用GCC 4.9.0构建一个向后兼容的二进制文件libstdc++.根据GCC的ABI策略和指南以及控制C++方言的选项,命令行选项-fabi-version应该可以解决问题; 但是,无论我设置哪个版本,我仍然可以从更新的版本导入符号,如下所示:

$ objdump -T binary | grep GLIBCXX_3.4.20
00000000      DF *UND*  00000000  GLIBCXX_3.4.20 _ZSt24__throw_out_of_range_fmtPKcz

我试图-fabi-version=1到-fabi-version=5(ABI版本5个对应于GCC 4.6,这是保证是存在于目标系统上),但这些进口保持在所得到的文件卷绕.

我该如何解决？由于其他原因,回到旧的GCC版本不是我的选择.

根据http://flamingdangerzone.com/cxx11/2012/07/06/optimal-tuple-i.html,关于std :: tuple ...

libstdc ++总是以相反的顺序放置成员,而libc ++总是按给定的顺序放置成员

假设这是真的,有没有理由(历史或其他)为什么libstdc ++使用逆序？

额外奖励:是否有任何实现因任何原因改变了其std :: tuple排序？

看看这个:

#include <iostream>
#include <memory>

using Foo = int;
using FooPtr = std::shared_ptr<Foo>;

FooPtr makeFoo()
{
    FooPtr f{
        new Foo(),
        [](Foo* ptr) {
            delete ptr;

            std::cerr << "!\n";
        }
    };

    return f;
}

void bar(FooPtr p = {})
{
    p = makeFoo();
}

int main()
{
    bar();
}

// Expected output: '!'
// Failure case: no output (deleter not invoked?)

我希望shared_ptr在bar()返回时调用删除器,在使用GCC 4.8.5的64位CentOS 7系统上调用它.

然而,在我的32位的CentOS下devtoolset 2中使用GCC 4.8.2 6系统(我也想下gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_linux,我的树莓派工具链),它没有.

看一下代码,并给出了4.8中C++ 11的实验性质,这对我来说就像一个编译器错误.但我也可能陷入某个地方的UB陷阱(或者只是误解了这些东西应该如何工作).

谁有过错？我该如何解决？

适用于

Using …

Ubuntu Linux 上有一个名为的软件包libstdc++6-8-dbg（撰写本文时为最新版本）。

它被描述为：

GNU 标准 C++ 库 v3（调试文件） 该软件包包含使用调试符号编译的 libstdc++ 共享库。

除其他外，它还包含以下文件：

/usr/lib/x86_64-linux-gnu/debug/libstdc++.a
/usr/lib/x86_64-linux-gnu/debug/libstdc++.so.6.0.25
/usr/lib/x86_64-linux-gnu/debug/libstdc++fs.a

通常，要使用 gcc 编译（单个翻译单元）C++ 程序，您可以编写：

$ g++ myprogram.cc

要添加用户代码的调试符号的生成，请传递-g：

$ g++ -g myprogram.cc

但这不包括标准库的调试版本。

您需要传递哪些额外选项g++来告诉它使用 提供的标准库的调试版本libstdc++6-8-dbg？

假设我有以下本地 gcc, g++ 版本：

$ gcc -v
$ g++ -v
gcc version 6.3.1

与我的编译器版本相比，我不理解以下内容的关系和含义：

这是指什么？

/usr/lib64/libstdc++.so.6

尝试运行二进制文件时出现此错误，这是GLIBCXX_3.4.20指什么？为什么数字以3开头？

/lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found

这是什么？

$ strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19

ldd版本怎么样？

ldd --version
ldd (GNU libc) 2.17

我无法将所有这些版本号链接在一起。

我试图在 rstudio 中加载 Seurat 包并收到此错误

Error: package or namespace load failed for \xe2\x80\x98Seurat\xe2\x80\x99 in dyn.load(file, DLLpath = DLLpath, ...):\n unable to load shared object '/wdata/msmuhammad/workbench/miniconda3/envs/test2/lib/R/library/Rcpp/libs/Rcpp.so':\n  /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /wdata/msmuhammad/workbench/miniconda3/envs/test2/lib/R/library/Rcpp/libs/Rcpp.so)\n

我在 conda 环境中使用 rstudio

我发现了一个关于没有版本“GLIBCXX_3.4.26”的相同问题的问题。这导致我运行这个命令

strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep GLIBCXX \n

我得到了这个：

GLIBCXX_3.4\nGLIBCXX_3.4.1\nGLIBCXX_3.4.2\nGLIBCXX_3.4.3\nGLIBCXX_3.4.4\nGLIBCXX_3.4.5\nGLIBCXX_3.4.6\nGLIBCXX_3.4.7\nGLIBCXX_3.4.8\nGLIBCXX_3.4.9\nGLIBCXX_3.4.10\nGLIBCXX_3.4.11\nGLIBCXX_3.4.12\nGLIBCXX_3.4.13\nGLIBCXX_3.4.14\nGLIBCXX_3.4.15\nGLIBCXX_3.4.16\nGLIBCXX_3.4.17\nGLIBCXX_3.4.18\nGLIBCXX_3.4.19\nGLIBCXX_3.4.20\nGLIBCXX_3.4.21\nGLIBCXX_3.4.22\nGLIBCXX_3.4.23\nGLIBCXX_3.4.24\nGLIBCXX_3.4.25\nGLIBCXX_DEBUG_MESSAGE_LENGTH\n

因此，它没有所需的版本，我无法从终端安装 libstdc++，因为该步骤需要 sudo 命令，而我不是 sudo 者之一，而且我一直被拒绝许可。

乌班图18.04.6

Linux 4.15.0-154-通用

那么除了sudo命令之外还有什么办法可以解决这个问题呢？

我在 conda 环境中尝试了这个命令

strings msmuhammad/workbench/miniconda3/envs/test2/lib/libstdc++.so.6 | grep GLIBCXX\n

我得到了这个

GLIBCXX_3.4\nGLIBCXX_3.4.1\nGLIBCXX_3.4.2\nGLIBCXX_3.4.3\nGLIBCXX_3.4.4\nGLIBCXX_3.4.5\nGLIBCXX_3.4.6\nGLIBCXX_3.4.7\nGLIBCXX_3.4.8\nGLIBCXX_3.4.9\nGLIBCXX_3.4.10\nGLIBCXX_3.4.11\nGLIBCXX_3.4.12\nGLIBCXX_3.4.13\nGLIBCXX_3.4.14\nGLIBCXX_3.4.15\nGLIBCXX_3.4.16\nGLIBCXX_3.4.17\nGLIBCXX_3.4.18\nGLIBCXX_3.4.19\nGLIBCXX_3.4.20\nGLIBCXX_3.4.21\nGLIBCXX_3.4.22\nGLIBCXX_3.4.23\nGLIBCXX_3.4.24\nGLIBCXX_3.4.25\nGLIBCXX_3.4.26\nGLIBCXX_3.4.27\nGLIBCXX_3.4.28\nGLIBCXX_3.4.29\nGLIBCXX_DEBUG_MESSAGE_LENGTH\n_ZNKSt14basic_ifstreamIcSt11char_traitsIcEE7is_openEv@GLIBCXX_3.4\n_ZNSt13basic_istreamIwSt11char_traitsIwEE6ignoreEv@@GLIBCXX_3.4.5\n_ZNKSbIwSt11char_traitsIwESaIwEE11_M_disjunctEPKw@GLIBCXX_3.4\n_ZNKSt14basic_ifstreamIwSt11char_traitsIwEE7is_openEv@@GLIBCXX_3.4.5\nGLIBCXX_3.4.21\nGLIBCXX_3.4.9\n_ZSt10adopt_lock@@GLIBCXX_3.4.11\nGLIBCXX_3.4.10\nGLIBCXX_3.4.16\nGLIBCXX_3.4.1\n_ZNSt19istreambuf_iteratorIcSt11char_traitsIcEEppEv@GLIBCXX_3.4\nGLIBCXX_3.4.28\n_ZNSs7_M_copyEPcPKcm@GLIBCXX_3.4\nGLIBCXX_3.4.25\n_ZNSt19istreambuf_iteratorIcSt11char_traitsIcEEppEv@@GLIBCXX_3.4.5\n_ZNSs7_M_moveEPcPKcm@@GLIBCXX_3.4.5\n_ZNKSt13basic_fstreamIwSt11char_traitsIwEE7is_openEv@GLIBCXX_3.4\n_ZNKSt13basic_fstreamIcSt11char_traitsIcEE7is_openEv@GLIBCXX_3.4\n_ZNSbIwSt11char_traitsIwESaIwEE4_Rep26_M_set_length_and_sharableEm@@GLIBCXX_3.4.5\n_ZNSs4_Rep26_M_set_length_and_sharableEm@GLIBCXX_3.4\n_ZSt10defer_lock@@GLIBCXX_3.4.11\n_ZN10__gnu_norm15_List_node_base4swapERS0_S1_@@GLIBCXX_3.4\n_ZNSs9_M_assignEPcmc@@GLIBCXX_3.4.5\n_ZNKSbIwSt11char_traitsIwESaIwEE15_M_check_lengthEmmPKc@@GLIBCXX_3.4.5\n_ZNKSt14basic_ifstreamIcSt11char_traitsIcEE7is_openEv@@GLIBCXX_3.4.5\n_ZNSbIwSt11char_traitsIwESaIwEE7_M_moveEPwPKwm@GLIBCXX_3.4\nGLIBCXX_3.4.24\n_ZNVSt9__atomic011atomic_flag12test_and_setESt12memory_order@@GLIBCXX_3.4.11\nGLIBCXX_3.4.20\n_ZNSt11char_traitsIwE2eqERKwS2_@@GLIBCXX_3.4.5\nGLIBCXX_3.4.12\n_ZNSi6ignoreEv@@GLIBCXX_3.4.5\nGLIBCXX_3.4.2\n_ZNSt11char_traitsIcE2eqERKcS2_@@GLIBCXX_3.4.5\nGLIBCXX_3.4.6\nGLIBCXX_3.4.15\n_ZNKSt13basic_fstreamIcSt11char_traitsIcEE7is_openEv@@GLIBCXX_3.4.5\n_ZNSs9_M_assignEPcmc@GLIBCXX_3.4\nGLIBCXX_3.4.19\n_ZNKSt14basic_ofstreamIwSt11char_traitsIwEE7is_openEv@GLIBCXX_3.4\n_ZNSt19istreambuf_iteratorIwSt11char_traitsIwEEppEv@GLIBCXX_3.4\nGLIBCXX_3.4.27\n_ZN10__gnu_norm15_List_node_base7reverseEv@@GLIBCXX_3.4\n_ZN10__gnu_norm15_List_node_base4hookEPS0_@@GLIBCXX_3.4\n_ZNSt11char_traitsIwE2eqERKwS2_@GLIBCXX_3.4\n_ZNSbIwSt11char_traitsIwESaIwEE7_M_copyEPwPKwm@GLIBCXX_3.4\n_ZNSbIwSt11char_traitsIwESaIwEE7_M_copyEPwPKwm@@GLIBCXX_3.4.5\nGLIBCXX_3.4.23\nGLIBCXX_3.4.3\nGLIBCXX_3.4.7\n_ZNSi6ignoreEl@@GLIBCXX_3.4.5\n_ZNKSbIwSt11char_traitsIwESaIwEE11_M_disjunctEPKw@@GLIBCXX_3.4.5\n_ZNSt13basic_istreamIwSt11char_traitsIwEE6ignoreEv@GLIBCXX_3.4\n_ZNKSt13basic_fstreamIwSt11char_traitsIwEE7is_openEv@@GLIBCXX_3.4.5\n_ZNSbIwSt11char_traitsIwESaIwEE7_M_moveEPwPKwm@@GLIBCXX_3.4.5\nGLIBCXX_3.4.18\n_ZNSbIwSt11char_traitsIwESaIwEE4_Rep26_M_set_length_and_sharableEm@GLIBCXX_3.4\n_ZNSt13basic_istreamIwSt11char_traitsIwEE6ignoreEl@@GLIBCXX_3.4.5\n_ZSt15future_category@@GLIBCXX_3.4.14\n_ZNSi6ignoreEl@GLIBCXX_3.4\nGLIBCXX_3.4.29\n_ZNSt11char_traitsIcE2eqERKcS2_@GLIBCXX_3.4\n_ZNKSs15_M_check_lengthEmmPKc@GLIBCXX_3.4\n_ZN10__gnu_norm15_List_node_base8transferEPS0_S1_@@GLIBCXX_3.4\n_ZNSbIwSt11char_traitsIwESaIwEE9_M_assignEPwmw@GLIBCXX_3.4\n_ZNVSt9__atomic011atomic_flag5clearESt12memory_order@@GLIBCXX_3.4.11\n_ZNKSt14basic_ofstreamIcSt11char_traitsIcEE7is_openEv@@GLIBCXX_3.4.5\n_ZNKSt14basic_ofstreamIcSt11char_traitsIcEE7is_openEv@GLIBCXX_3.4\n_ZNSs7_M_moveEPcPKcm@GLIBCXX_3.4\n_ZNSt13basic_istreamIwSt11char_traitsIwEE6ignoreEl@GLIBCXX_3.4\n_ZNSbIwSt11char_traitsIwESaIwEE9_M_assignEPwmw@@GLIBCXX_3.4.5\n_ZNKSbIwSt11char_traitsIwESaIwEE15_M_check_lengthEmmPKc@GLIBCXX_3.4\n_ZNKSs11_M_disjunctEPKc@@GLIBCXX_3.4.5\n_ZN10__gnu_norm15_List_node_base6unhookEv@@GLIBCXX_3.4\nGLIBCXX_3.4.22\n_ZNSt19istreambuf_iteratorIwSt11char_traitsIwEEppEv@@GLIBCXX_3.4.5\n_ZNSi6ignoreEv@GLIBCXX_3.4\n_ZNSs7_M_copyEPcPKcm@@GLIBCXX_3.4.5\nGLIBCXX_3.4.8\nGLIBCXX_3.4.13\n_ZSt11try_to_lock@@GLIBCXX_3.4.11\n_ZNKSt14basic_ofstreamIwSt11char_traitsIwEE7is_openEv@@GLIBCXX_3.4.5\nGLIBCXX_3.4.17\nGLIBCXX_3.4.4\n_ZNKSs15_M_check_lengthEmmPKc@@GLIBCXX_3.4.5\n_ZNKSt14basic_ifstreamIwSt11char_traitsIwEE7is_openEv@GLIBCXX_3.4\n_ZNSs4_Rep26_M_set_length_and_sharableEm@@GLIBCXX_3.4.5\nGLIBCXX_3.4.26\n_ZNKSs11_M_disjunctEPKc@GLIBCXX_3.4\n …