尝试编译我的程序时,我有一个未解决的符号错误,抱怨它无法找到__dso_handle.这个函数通常定义在哪个库中？
以下结果是否nm on libstdc++.so.6意味着包含它？
我试图链接它,但错误仍然发生.
nm libstdc++.so.6 | grep dso
00000000002fc480 d __dso_handle
我们最近收到了一份报告,因为GCC 5.1,libstdc ++和Dual ABI.似乎Clang不知道GCC内联命名空间更改,因此它基于一组命名空间或符号生成代码,而GCC使用另一组命名空间或符号.在链接时,由于缺少符号而存在问题.
如果我正确地解析双ABI页面,它看起来像是一个转动的问题,_GLIBCXX_USE_CXX11_ABI并abi::cxx11带来一些额外的困难.Red Hat的博客可以在GCC5和C++ 11 ABI以及GCC-5.1案例和两个C++ ABI上阅读更多内容.
下面是一台Ubuntu 15机器.该机器提供GCC 5.2.1.
$ cat test.cxx
#include <string>
std::string foo __attribute__ ((visibility ("default")));
std::string bar __attribute__ ((visibility ("default")));
$ g++ -g3 -O2 -shared test.cxx -o test.so
$ nm test.so | grep _Z3
...
0000201c B _Z3barB5cxx11
00002034 B _Z3fooB5cxx11
$ echo _Z3fooB5cxx11 _Z3barB5cxx11 | c++filt
foo[abi:cxx11] bar[abi:cxx11]
如何使用两个装饰生成带符号的二进制文件(红帽博客称之为"共存")？
或者,我们可以选择哪些选项？
我正试图为用户实现"它只是工作".我不在乎是否存在两个具有两种不同行为的弱符号(std::string缺少写时std::string[abi:cxx11]复制,同时提供写时复制).或者,一个可以是另一个的别名.
Debian在Debian Bug报告日志中 …
对于在许多工具链API/ABI兼容性与相同的二进制,这是很好 众所周知 的是 STL容器,std::string和其他标准库类,如输入输出流被禁止的公共报头.(例外情况是,如果为每个受支持的工具链版本分配一个构建;一个为最终用户编译提供没有二进制文件的源,在本例中不是首选选项;或者一个转换为其他一些内联容器,以便不同的std实现不会被库提取.)
如果已经有一个已发布的库API没有遵循此规则(请求朋友),那么最好的路径是什么,同时保持尽可能多的向后兼容性,并且我不能支持编译时断点？我需要支持Windows和Linux.
重新考虑我正在寻找的ABI兼容性水平:我不需要它是疯狂的未来证明.我主要是为每个版本的多个流行的Linux发行版只做一个库二进制文件.(目前,我为每个编译器发布一个,有时为特殊发行版(RHEL vs Debian)发布特殊版本.与MSVC版本相同的问题 - 所有支持的MSVC版本的一个DLL将是理想的.)其次,如果我不'在破解修复版本中打破API,我希望它与ABI兼容,并且无需重建客户端应用程序即可替换掉DLL/SO.
我有三个案例,有一些初步建议,模仿Qt到一定程度.
旧的公共API:
// Case 1: Non-virtual functions with containers
void Foo( const char* );
void Foo( const std::string& );
// Case 2: Virtual functions
class Bar
{
public:
virtual ~Bar() = default;
virtual void VirtFn( const std::string& );
};
// Case 3: Serialization
std::ostream& operator << ( std::ostream& os, const Bar& bar );
从理论上讲,我们可以将std::string使用转换为非常类似于std::string_view我们库的API/ABI控件的类.它将在我们的库头中进行转换,std::string以便编译的库仍然接受但是独立于std::string实现并且向后兼容:
新API:
class …