如何在g ++中链接同一库的不同版本? [英] How do I link different versions of the same library in g++?

查看:78
本文介绍了如何在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屋!

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