c++ - 动态链接库 - 构建可执行文件时成功，创建另一个 .so 时相同的设置失败

Question

我正在写一个数字代码，我想在其中使用第三方编写的共享库。我正在 CentOS 下开发 x86_64 k8 架构。我想要构建的理想目标是 Python 或 Matlab 扩展模块，据我所知，它们是 gcc 构建的动态链接共享库，内置额外的 Matlab/Python 脚手架。我将重点关注在 Python 上，因为同样的问题发生了，社区可能更熟悉。

库开发人员最初为我提供了动态库和一些用 C++ 编写的测试代码。这就是他打算如何分发他的图书馆。我应该注意，我正在尝试尽可能减少原始开发人员的负担，因为该库可能在​​一段时间前对他来说是一个副项目，并且他的测试代码最终运行正常。因此，我正在尽我所能解决我这边的问题。我设法将他的示例构建为可执行文件，仅使用 gcc 4.5.0。我使用的常用 gcc 版本 4.1.2 在链接(使用 g++)期间产生了四个“ undefined reference ”错误，特别是 _M_insert<long>(long) , _M_widen_init() , _M_insert<double>(double)和 __ostream_insert<char, std::char_traits<char> > .这些都是std的一部分命名空间。使用 g++ 4.5.0 编译解决了这些 undefined reference 并且示例可执行文件正确运行。根据 E.R. 的评论，readelf -x.comment libmaxent_k8.so , 表示原始库是使用 gcc 4.4.1 构建的。

为了测试链接到 Python 扩展是否有效，我用 C++ 构建了一个小型 Python 扩展函数，它只添加两个数字。具体来说，它不使用我想使用的库中的任何内容。该界面是 SWIG 2.0 生成的，使用 g++ 4.50 编译。代码在 Python 2.4.3 中运行良好。但是，当我尝试链接到原始库时，没有从中引用任何符号，代码再次链接正常，但是在运行时，在导入扩展时，我得到 ImportError: libmaxent_k8.so: undefined symbol: _ZNSo9_M_insertIlEERSoT_ , 其中, 通过c++filt , 是 _M_insert(long) ，这是原始代码之一，在使用 g++ 4.1.2 链接 C++ 代码时未定义。

我怀疑问题是在 python 的链接和运行时不匹配的 libstdc++ 版本，但我不知道如何解决这个问题。对我来说最好的情况是在链接扩展时让我在没有 gcc 4.5.0 的情况下以某种方式逃脱，也许我在解决最初的 4 个缺失引用问题时跳到了前面。这个问题可以通过以某种方式静态链接到 libstdc++ 6.0.14(它是 gcc 4.5.0 的一部分)的 bing 构建来解决，同时仍然保留它们作为动态链接库的特性吗？尽管 Python 与 gcc 4.5.0 配合没有问题，但 Matlab 有，并且他们的支持声称可靠性仅达到 gcc 4.2.0。出于这个原因，我想尽可能少地使用 4.5.0 进行编译。我的 gcc 带有 6.0.8 版本的 libstdc++。

以下是有关图书馆的一些报告。请记住，尽管有所有这些引用，代码在直接编译为可执行文件时仍然有效。

$ readelf -aD /home/mbudisic/lib64/libmaxent_k8.so | grep NEEDED
0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

$ ldd -d libmaxent_k8.so 
undefined symbol: _ZSt4cerr (./libmaxent_k8.so)
undefined symbol: _ZNSt8ios_base4InitD1Ev   (./libmaxent_k8.so)
undefined symbol: _ZSt4cout (./libmaxent_k8.so)
undefined symbol: __gxx_personality_v0  (./libmaxent_k8.so)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002b92457f3000)
    libc.so.6 => /lib64/libc.so.6 (0x00002b9245a01000)
    /lib64/ld-linux-x86-64.so.2 (0x000000366e200000)

正在运行 nm -uC libmaxent_k8.so导致来自 libm 和 libstdc++ 库的 35 个“U”标记符号和两个“w”标记符号，这远远超过链接/运行中报告为未定义的数量。

Answer 1

一般来说，glibc 和 libstdc++ 试图提供向后兼容性——在旧系统(或旧 GCC)上构建的二进制文件继续在新系统上运行。

相反:在 glibc-2.5 系统上运行与 glibc-2.10 链接的二进制文件，或针对 GCC-4.2 附带的 libstdc++ 运行使用 GCC-4.4 构建的二进制文件是非目标。

因此，您必须要求使用您想要支持的最旧的 GCC(在您的情况下是 4.2)构建的二进制文件，或者安排使用新的 libstdc++(通过修改 LD_LIBRARY_PATH，或通过对 Matlab 和 Python 使用 LD_PRELOAD)。

glibc的向后兼容性很好，但是libstdc++的记录比较参差不齐；所以 Matlab 声称只有 libstdc++.so.6.0.8 是稳定和受支持的，这很可能是正确的。您只需要尝试一下，因为(除非您获得使用 GCC-4.2 构建的 libmaxent_k8.so)您没有任何其他选择(我能想到)。