发现此声明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 std库,C可执行文件通常链接到MSVCR*.DLL,对于驻留在此DLL中的STL的内容,通常链接到MSVCP*.DLL.这两者都驻留在system32目录中,或者,对于显示的东西,它们将驻留在Windows SideBySide缓存(winsxs文件夹)的子目录中.
我从未见过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.
这让我想知道他是否仅仅指你自己使用dlopen().但是它也工作得很好,除非你没有将.so链接到你的libstdc .so(这将是你自己的错;如果你依赖于任何其他库,无论用什么语言编写它都会是同样的问题在).
