Ric*_*eur 8 linker gcc build libstdc++
我想在前面加上一个重要的通知,我不是一个C/C++程序员,并且很少知道库的链接如何在C中工作.
我们的代码使用libstdc ++.so.6(gcc 3.4,我认为).我们有第三方预编译(闭源)库使用libstdc ++.so.5(gcc 2.something或3.2,我认为).这是在Linux上.我们有第三方库的.a和.so版本.
是否可以使用第三方库构建我们的应用程序?怎么样?是否有可能在没有libstdc ++的情况下构建/运行我们的应用程序.so.5安装了我们的机器,怎么样?
如果我忘记了一些重要信息,请告诉我 - 我几乎不知道这些东西是什么.我意识到完全答案可能是不可能的; 我真的在寻找方向和指导.静态链接,动态,重建,预建某某,切换到版本x,或者符号链接quizdoodle等.
更新:
我们尝试使用dlopenwith RTLD_LOCAL将第三方库与我们应用程序的其余部分隔离开来.这似乎大部分都有效,但是,由于未知原因,我们留下了大量内存泄漏.我们怀疑,当我们调用时dlopen,第三方库会malloc从已经加载的.so.6中提取符号,并且事情变得混乱.
对于咯咯笑,我们尝试将第三方库放入LD_PRELOAD,然后运行我们的应用程序,内存泄漏似乎完全消失.
您可以尝试围绕第三方库构建一个包装器库:使用该库的静态版本+将其与静态标准库链接(-static-libgcc - 确保通过-L获取正确的版本).重要的是要正确关闭这个包装器库,即只导出原始第三方库中的符号,其他所有内容都应该被隐藏.这样,包装器库将为您的应用程序公开所有需要的符号,并将标准内容封装在其中.请注意,如果您的代码和第三方代码之间共享某些内存操作(例如,您在代码中分配内存并在第三方中取消分配),则无法保证可以正常工作...在这种情况下,唯一的选择是保持第3个在不同的进程空间中的方lib.
我不认为上面提到的动态选项会起作用,因为你会得到完全相同的问题 - 稍后.
通常,最好不要在同一进程空间中混合具有不同运行时间的二进制文件.它几乎总是灾难的秘诀.
| 归档时间: |
|
| 查看次数: |
2725 次 |
| 最近记录: |