在Linux上如何从一个纯C项目中使用一个用C++编写的库?

5
发现这个声明在PSE上:(引用Bob
“我在Windows和Mac OS上最喜欢的技巧之一在Linux上不起作用。这个技巧是使用C++内部编写DLL / dylib,导出C API,然后能够从C程序调用它。 Linux共享对象(DLL的本地等效项)不能很容易地做到这一点,因为C ++标准库.so不在默认搜索路径中。如果您不对C程序进行一些奇怪的处理,它将在运行时动态加载您的.so时立即失败:您的.so将尝试动态加载标准库.so,它找不到它,然后您的程序将退出。”
我觉得这有点奇怪。考虑到Linux主要桌面/服务器发行版之间可能存在的差异,这有多准确?
至于Windows,我必须查一下,我会把它放在这里供参考: C++可执行文件通常会链接到MSVCR*.DLL C标准库和MSVCP*.DLL STL的内容,这些内容驻留在此DLL中。这两个都驻留在system32目录中,或者对于清单化的东西,它们将驻留在Windows SideBySide缓存的子目录中( winsxs文件夹)。

6
我觉得有点奇怪。这准确吗? 是的,这很奇怪。不,这不准确。另外,“the linux”这种说法是不存在的(发行版不同)。 - sehe
@sehe - 看起来对于主要的发行版而言,差异如此显著似乎有点奇怪。 - Martin Ba
@sehe - 是的,但对于2010版本来说,如果我没记错的话,它回到了system32文件夹。 - Martin Ba
1
我并不是说所有的发行版都没有在搜索路径中包含libstdc++位;我是说这种奇怪的情况可能会出现在某些外国Linux发行版上(比如用于冰箱中的爱普生芯片的嵌入式Linux?) - sehe
2
我一直在做这件事情,而且它运行得很好。我非常确定那个人有一个完全无关的问题,并将库搜索路径归咎于此。我从未见过任何Linux系统没有将libstdc++放在/usr/lib[64]/路径下。 - PlasmaHH
显示剩余2条评论
1个回答

4
我一直在做这件事,它运行得很好。我非常确定那个人有一个完全无关的问题,并把库搜索路径归咎于它。
我从未见过任何Linux发行版没有将libstdc++.so放在/usr/lib [64]/路径中。
这也让我想知道C++程序通常如何为该用户工作,因为据我所知,.so文件的搜索路径与语言无关。
也许他总是使用特殊版本并使用-rpath链接器选项编译所有程序?但即使是这样,仅向他的C程序添加该选项也可以解决问题。
当你的.so在运行时动态加载时,它将立即失败:你的.so将尝试动态加载标准库.so,但它找不到,然后你的程序将退出。
这让我想知道他是否仅仅指的是在自己的.so上使用dlopen()。但即使是这样,它也能正常工作,除非您没有将.so链接到您的libstdc++.so(如果是这样,那就是您自己的问题。如果您依赖于任何其他库,则会出现相同的问题,无论它是用哪种语言编写的)。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接