【问题标题】:Using a library written in C++ from a pure C project on Linux?在 Linux 上使用纯 C 项目中用 C++ 编写的库?
【发布时间】: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

标签: c++ c windows linux shared-libraries


【解决方案1】:

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

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

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

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

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

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

【讨论】:

    猜你喜欢
    • 2017-03-12
    • 1970-01-01
    • 1970-01-01
    • 2012-05-19
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-03-14
    • 2013-04-07
    相关资源
    最近更新 更多