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

Posted 2023-02-21

【中文标题】在 Linux 上使用纯 C 项目中用 C++ 编写的库？

【英文标题】：Using a library written in C++ from a pure C project on Linux?

【发布时间】：2011-09-30 11:30:26

【问题描述】：

找到这个声明over at PSE:（引用Bob）

我在 Windows 和 Mac OS 上最喜欢的技巧之一在 Linux 上不起作用。 这个技巧是使用 C++ 内部编写一个 DLL/dylib，导出一个 C API，然后能够从 C 程序中调用它。 Linux 共享 对象（DLL 的本地等价物）不能真正轻松地做到这一点， 因为 C++ 标准库 .so 不在默认搜索路径中。 如果你不对你的 C 程序做一堆奇怪的事情，它就会失败 只要它在运行时动态加载您的 .so ：您的 .so 将尝试 动态加载标准库.so，它不会找到它，并且 那么你的程序就会退出。

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

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

---

至于 Windows，我不得不进行一些查找，并将其放在这里以供参考： C++ 可执行文件通常会链接到 MSVCR*.DLL 用于 C 标准库，MSVCP*.DLL 用于驻留在此 DLL 中的 STL 的东西。这两个都驻留在 system32 目录中，或者，对于已显示的内容，它们将驻留在 Windows SideBySide 缓存的子目录中（winsxs 文件夹）。

【问题讨论】：

I find that a bit odd. Is this accurate? 是的，这很奇怪。不，它不准确。此外，没有“linux”之类的东西（发行版不同）

请注意（从内存中：）VS2008+ MSVC 运行时必须由清单加载（否则您的程序会在加载时报错）

@sehe - 主要发行版的显着差异似乎很奇怪。

我并不是说搜索路径中没有 libstdc++ 位的发行版；我是说对于某些外国 Linux 发行版来说奇怪的说法可能是正确的（Embedded Linux For Epson Chipsets Used In Refridgerators?）

我一直在做这件事，而且效果很好。我很确定那个人有一个完全不相关的问题，并将其归咎于图书馆搜索路径。我从未见过任何 libstdc++ 不在 /usr/lib[64]/ 路径中的 linux

【参考方案1】：

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

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

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

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

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

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