如何在内部使用 C++ 异常并且可以在旧平台上运行的 linux x64 上创建共享库对象？答案

【问题标题】：How to create a shared library object on linux x64 which internally uses C++ exceptions and can run on older platforms?如何在内部使用 C++ 异常并且可以在旧平台上运行的 linux x64 上创建共享库对象？
【发布时间】：2016-04-06 15:20:52
【问题描述】：

如何在一个 Linux x64（例如 Red Hat 7.x）平台上创建一个内部使用 C++ 异常（没有跨越 .so 边界的异常）的基于 C++ 的共享库，以使其可以运行在其他与共享库兼容的 ABI 平台（例如 Red Hat 5.x 或 Red Hat 8.x）上？

.so 不使用 C++ 标准库（除了），但在内部使用 C++ 异常。它的外部 API 仅为 C，所有异常都在内部捕获（包括使用“catch(...)”以确保安全）。

现在的经验是，尽管在 GLIBC 中进行了版本控制，但使用 GCC 4.7.2 构建并由主程序通过 dlopen 加载的 .so 确实在具有 2.12 版 libc.so.6 等的系统上运行，但不是一个 2.5 版本的系统，在抛出异常时会发生奇怪的 abort() 和 terminate() 调用。

.so 是使用“-fabi-version=2”编译的。在任何平台上都不会发生链接器/加载器错误。

所以我的问题是如何完成构建这样一个可以在旧平台上运行的 .so 的任务？应该是可以的。

【问题讨论】：

我对不得不处理 LINUX/UNIX 表示哀悼。我正在遭受同样的命运。避免使用 Linux/UNIX。使用一个系统（我不会告诉你名字），它能够（自 20 年以来）在单个进程中处理多个不同的运行时库，并且不会遇到 std:: 总是以弱符号（无法隐藏 std 命名空间中的符号，即使它是 std::vector<:yourclass>）。

标签： c++ linux exception shared platform

【解决方案1】：

在 Linux 上，g++ 中的 libstdc++ 和 libgcc_s 链接到您的可执行文件和共享库。

我会尝试使用-static-libgcc 和-static-libstdc++ 将它们静态链接到您的共享库中。然后检查ldd my.so 输出以确保您的共享库不会链接不需要的.so。

【讨论】：