如何在g ++中链接同一库的不同版本? [英] How do I link different versions of the same library in g++?
问题描述
我试图弄清楚如何在SLES10机器上加载libstdc ++.so的两个不同版本.我的客户端有一个Foo进程,它是用GCC 4.1.2构建的,因此使用libstdc ++.so的6.0.8版本.我们还将建立名为libBar.so的共享库.该库将由Foo在运行时动态加载. libBar.so使用GCC 4.3.6和libstdc ++版本6.0.10进行编译.
I'm trying to figure out how to load two different versions of libstdc++.so on a SLES10 machine. My client has a process Foo, which is built with GCC 4.1.2, and thus uses the 6.0.8 version of libstdc++.so. We are also building shared library called libBar.so. This library will be dynamically loaded by Foo at runtime. libBar.so is compiled using GCC 4.3.6, and libstdc++ version 6.0.10.
当前,当我尝试让Foo加载libBar.so时,出现以下错误.
Currently, when I try to have Foo load libBar.so, I get the following error.
错误:无法加载共享对象 '/usr/lib64/libBar.so': /usr/lib64/libstdc++.so.6:找不到版本"GLIBCXX_3.4.9" (/usr/lib64/libBar.so所需)
error: unable to load shared object '/usr/lib64/libBar.so': /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /usr/lib64/libBar.so)
目前,使此功能起作用的唯一方法是更改我的库加载顺序(通过ld.so.conf),以便Foo和libbar.so都加载相同的(6.0.10)libstdc ++.所以.但是,这不是解决方案,因为它要求我修改客户端的系统.
At the moment, the only way that I can get this to work is to change my library load order (via ld.so.conf) so that Foo and libbar.so both load the same (6.0.10) libstdc++.so. However, this isn't a vialbe solution, since it requires that I modify the client's system.
我想做的是Foo加载它的libstdc ++.so和libBar.so版本链接到它自己的libstdc ++.so版本,但是我不知道如何编写Makefile来实现这一目标. .到目前为止,这是我在Makefile.am中使用LIBADD行的结果.
What I'd like to do is have Foo load it's verions of libstdc++.so and libBar.so link to it's own version of libstdc++.so, but I can't figure out how to write my Makefile to make that happen. Here's what I have so far, for my LIBADD line in Makefile.am...
libBar_la_LIBADD = ../../vendor/SLES10/lib/libstdc ++.so.6.0.10
libBar_la_LIBADD = ../../vendor/SLES10/lib/libstdc++.so.6.0.10
我想假设要使用libstdc ++.so的特定版本.但是,当我对完全编译并链接的libBar.so运行ldd时,这是我看到的行...
Which I would assume would like to that SPECIFIC version of libstdc++.so. However, when I run ldd against the fully compiled and linked libBar.so, this is the line I see...
libstdc ++.so.6 =>/usr/lib64/libstdc++.so.6(0x00002aaaaeac5000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002aaaaeac5000)
为什么它不专门链接到libstdc ++.so.6.0.10?我应该怎么做呢?
Why isn't it linking specifically to libstdc++.so.6.0.10? What should I be doing instead?
推荐答案
我对使用过时版本libstdc++
的第三方库也遇到了类似的问题.
I had a similar issue with a 3rd-party library that used an obsolete version of libstdc++
.
我通过将第3方库与旧版本的libstdc++
静态预先链接起来解决了该问题.最终结果是另一个没有未解析的libstdc++
符号的共享库.命令行是这样的:
I solved it by pre-linking the 3rd-party library statically with that old version of libstdc++
. The end result was another shared library that did not have unresolved libstdc++
symbols. The command line was something like this:
ld --relocatable -o lib3rd-party-prelinked.so lib3rd-party.so /usr/lib64/libstdc++.a.6
然后我使用lib3rd-party-prelinked.so
而不是lib3rd-party.so
. (在man ld
中查找--relocatable
).
And then I used lib3rd-party-prelinked.so
instead of lib3rd-party.so
. (Lookup --relocatable
in man ld
).
在我看来,这是有可能的,因为第三方库公开了C API,其接口中没有使用C ++标准库组件.
It was possible in my case because the 3rd-party library exposed a C API, no C++ standard library components were used in its interface.
如果您的第三方库在其接口中公开了C ++标准库类,而这些CBI标准库类在这些libstdc++
版本之间的ABI不同,则将无法使用.例如.您的应用程序将带有新ABI的std::list<>
传递给希望使用旧ABI版本的std::list<>
的第三方库.即使链接,也会在运行时导致不确定的行为.
If your 3rd-party library exposes C++ standard library classes in its interface whose ABIs are different between these libstdc++
versions, that is not going to work. E.g. your application passes a std::list<>
with the new ABI to the 3rd-party library that expects a std::list<>
with the old ABI version. Even if it links, that will cause undefined behaviour at run-time.
这篇关于如何在g ++中链接同一库的不同版本?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!