c++ - 在 Linux 上使用纯 C 项目中用 C++ 编写的库？

Question

找到这条语句 over at PSE : (引用 Bob )

One of my favorite tricks on Windows and Mac OS doesn't work on Linux. That trick is to write a DLL/dylib using C++ internals, export a C API, and then be able to call into it from C programs. Linux shared objects (the local equivalent of a DLL) can't really do that easily, because the C++ standard library .so isn't in the default search path. If you don't do a bunch of weird stuff to your C program, it will fail as soon as it dynamically loads your .so at runtime: your .so will try to dynamically load the standard library .so, it won't find it, and then your program will exit.

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

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

---

至于 Windows，我不得不做一些查找，我会把它放在这里以供引用: C++ 可执行文件通常会链接到 MSVCR*.DLL对于 C std 库和 MSVCP*.DLL对于驻留在此 DLL 中的 STL 内容。这两者都驻留在 system32 目录中，或者，对于显示的内容，它们将驻留在 Windows SideBySide 缓存的子目录中(winsxs 文件夹)。

Answer 1

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

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

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

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

it will fail as soon as it dynamically loads your .so at runtime: your .so will try to dynamically load the standard library .so, it won't find it, and then your program will exit.

这让我想知道他是否只是指在您自己的 .so 上使用 dlopen()。但它也能正常工作，除非你没有将 .so 链接到你的 libstdc++.so (这将是你自己的错；这将是同样的问题你是否依赖于任何其他库，无论它是用什么语言编写的)。