在Linux上使用来自纯C项目的C++编写的库？

Question

在PSE发现此声明:(引用Bob)

Windows和Mac OS上我最喜欢的技巧之一不适用于Linux.这个技巧是使用C++内部编写DLL/dylib,导出C API,然后能够从C程序调用它.Linux共享对象(本地等效的DLL)无法轻易做到这一点,因为C++标准库.so不在默认搜索路径中.如果你没有为你的C程序做一些奇怪的事情,它会在运行时动态加载你的.so时失败:你的.so会尝试动态加载标准库.所以,它不会找到它,然后你的程序将退出.

我发现有点奇怪.这有多准确,考虑到Linux的主要桌面/服务器发行版之间可能存在的差异？

_{这纯粹是出于好奇,因为我目前只进行Windows(C++)编程.}

---

至于Windows中,我不得不做一些查询的,我会把它放在这里供参考:A C++可执行文件通常会链接到MSVCR*.DLL为C STD库和MSVCP*.DLL的STL的东西,驻留在这个DLL中.这两者都驻留在system32目录中,或者,对于显示的东西,它们将驻留在Windows SideBySide缓存(winsxs文件夹)的子目录中.

Answer 1

我一直在做这件事，而且效果很好。我很确定那个人遇到了一个完全不相关的问题，并将其归咎于图书馆搜索路径。

我从未见过任何 linux 发行版的路径libstdc++.so中没有/usr/lib[64]/。

这也让我想知道 C++ 程序通常如何为那个人工作，因为据我所知，.so文件的搜索路径与语言无关。

也许他总是使用特殊版本并使用链接器选项编译所有程序-rpath？但即便如此，只需将该选项添加到他的 C 程序中也可以。

一旦它在运行时动态加载你的.so，它就会失败：你的.so将尝试动态加载标准库.so，它不会找到它，然后你的程序将退出。

这让我怀疑他是否只是指dlopen()自己使用.so。但它也可以正常工作，除非你没有链接.so到你的libstdc++.so（这将是你自己的错；如果你依赖于任何其他库，无论它是用什么语言编写的，这都会是同样的问题）。