如何构建同时需要 libstdc++.so.5 和 libstdc++.so.6 的应用程序? [英] How to build an application that requires both libstdc++.so.5 and libstdc++.so.6?

查看:11
本文介绍了如何构建同时需要 libstdc++.so.5 和 libstdc++.so.6 的应用程序?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我想以重要的通知作为开头,即我不是 C/C++ 程序员,并且对 C 中的库链接如何工作知之甚少.

I want to preface this with the important notice that I am not a C/C++ programmer, and know very little about how linkage of libraries works in C.

我们的代码使用 libstdc++.so.6(我认为是 gcc 3.4).我们有使用 libstdc++.so.5(我认为是 gcc 2.something 或 3.2)的第三方预编译(闭源)库.这是在linux上.我们有第三方库的 .a 和 .so 版本.

Our code uses libstdc++.so.6 (gcc 3.4, i think). We have third-party precompiled (closed source) libraries that use libstdc++.so.5 (gcc 2.something or 3.2, i think). This is on linux. We have both a .a and .so version of the third party lib.

是否可以使用 3rd 方库构建我们的应用程序?如何?是否可以在没有安装 libstdc++.so.5 的情况下构建/运行我们的应用程序,如何?

Is it possible to build our app with the 3rd party libs? How? Is it possible to build/run our app without having libstdc++.so.5 installed our our machines, how?

如果我忘记了一些重要信息,请告诉我 - 我几乎不知道与这些内容有什么关系.我意识到一个完整的答案可能是不可能的;我真的在寻找方向和指导.静态链接 this、dynamic that、rebuild that、prebuild so-and-so、切换到版本 x 或符号链接 quizdoodle 等.

If I've forgotten some critical information, please let me know - I hardly know whats relevant with this stuff. I realize that a complete answer probably won't be possible; I'm really looking for direction and guidance. Static link this, dynamic that, rebuild that, prebuild so-and-so, switch to version x, or symlink the quizdoodle, etc.

更新:

我们尝试使用 dlopenRTLD_LOCAL 来将第 3 方库与我们应用的其余部分隔离开来.这似乎大部分起作用了,但是,由于未知原因,我们留下了大量的内存泄漏.我们怀疑,当我们调用 dlopen 时,第三方库会从已经加载的 .so.6 中拉入像 malloc 这样的符号,事情就会变得混乱.

We tried using dlopen with RTLD_LOCAL to isolate the 3rd party library from the rest of our app. This seems to have mostly worked, however, we are left with large memory leaks for unknown reasons. We suspect that, when we call dlopen, the third party library pulls in symbols like malloc from the already loaded .so.6, and things get muddled up.

为了傻笑,我们尝试将第三方库放入 LD_PRELOAD,然后运行我们的应用程序,内存泄漏似乎完全消失了.

For giggles, we tried putting the third-party library into LD_PRELOAD, then ran our app, and the memory leaks seems to completely disappear.

推荐答案

您可以尝试围绕您的 3rd 方库构建一个包装库:使用该库的静态版本 + 将其与静态标准库链接(-static-libgcc - 确保通过 -L 选择正确的版本).要做的重要事情是正确关闭此包装库,即只应导出原始第 3 方库中的符号,应隐藏其他所有内容.这样,您的包装库将为您的应用程序公开所有需要的符号并将标准内容封装在其中.请注意,特别是如果您的代码和第 3 方代码之间共享某些内存操作(例如,您在代码中分配内存并在第 3 方中取消分配),它不能保证工作......在这种情况下,唯一的选择是保留这个第 3派对库在不同的进程空间中.

You may try to build a wrapper library around your 3rd party library: use the static version of that library + link it with the static standard library (-static-libgcc - make sure you pick up a proper version via -L). The important thing to do is to close this wrapper library properly, i.e only symbols from the original 3rd party library should be exported, everything else should be hidden. This way you wrapper library will expose all needed symbols for your application and encapsulate standard stuff inside. Note it is not guaranteed to work especially if some memory operations are shared between your code and 3rd party code (e.g. you allocate memory in your code and deallocate in 3rd party)... in such case the only option can be to keep this 3rd party lib in a different process space.

我不认为上面提到的动态选项会起作用,因为你会遇到完全相同的问题 - 只是稍后.

I don't think the dynamic option mentioned above would work because you will get exactly same problem - just later.

一般来说,最好不要在同一进程空间中混合具有不同运行时间的二进制文件.这几乎总是灾难的根源.

In general it is better not to mix binaries with different run-times in the same process space. It is almost always a recipe for disaster.

这篇关于如何构建同时需要 libstdc++.so.5 和 libstdc++.so.6 的应用程序?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆