由于GCC 5.1, libstdc++ and Dual ABI,我们最近收到了一份报告。它似乎Clang is not aware of the GCC inline namespace changes,因此它基于一组命名空间或符号生成代码,而GCC使用另一组命名空间或符号。在链接时,由于缺少符号而存在问题。
如果我正确解析Dual ABI页面,那么看起来就像_GLIBCXX_USE_CXX11_ABI
和abi::cxx11
上的一些额外困难一样。 Red Hat的博客GCC5 and the C++11 ABI和The Case of GCC-5.1 and the Two C++ ABIs提供了更多阅读材料。
以下是来自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]
如何使用两种装饰生成带符号的二进制文件(&#34;共存&#34;红帽博客称之为)?
或者,我们可以选择哪些选项?
我试图实现&#34;它只是有效&#34;对于用户。我不在乎是否存在两个具有两种不同行为的弱符号(std::string
缺少写时复制,而std::string[abi:cxx11]
提供写时复制)。或者,一个可以是另一个的别名。
Debian在Debian Bug report logs: Bugs tagged libstdc++-cxx11有一大堆类似的错误。他们的解决方案是在新的ABI下重建所有内容,但它没有处理混合/匹配编译器模块化ABI更改的极端情况。
在Apple世界中,我认为这接近于胖二进制文件。但我不确定在Linux / GCC世界中该怎么做。最后,我们无法控制发行版如何构建库,我们也无法控制使用哪些编译器将应用程序与库链接。
答案 0 :(得分:9)
免责声明,以下内容未经生产测试,使用风险自负。
您可以在双ABI下自行发布您的图书馆。这或多或少类似于OSX“fat binary”,但完全用C ++构建。
最简单的方法是将库编译两次:-D_GLIBCXX_USE_CXX11_ABI=0
和-D_GLIBCXX_USE_CXX11_ABI=1
。将整个库置于两个不同的命名空间下,具体取决于宏的值:
#if _GLIBCXX_USE_CXX11_ABI
# define DUAL_ABI cxx11 __attribute__((abi_tag("cxx11")))
#else
# define DUAL_ABI cxx03
#endif
namespace CryptoPP {
inline namespace DUAL_ABI {
// library goes here
}
}
现在,您的用户可以像往常一样使用CryptoPP::whatever
,这会映射到CryptoPP::cxx11::whatever
或CryptoPP::cxx03::whatever
,具体取决于所选的ABI。
注意,GCC手册说这个方法会改变标记内联命名空间中定义的所有内容的错位名称。根据我的经验,这不会发生。
如果__attribute__((abi_tag("cxx11")))
非零,则另一种方法是使用_GLIBCXX_USE_CXX11_ABI
标记每个类,函数和变量。这个属性很好地将[cxx11]
添加到demangler的输出中。我认为使用命名空间同样适用,并且对现有代码的修改要求较少。
理论上,您不需要复制整个库,只需复制使用std::string
和std::list
的函数和类,以及使用这些函数的函数和类,类,等等递归。但在实践中,它可能不值得努力,特别是如果图书馆不是很大。
答案 1 :(得分:5)
这是一种方法,但它不是很优雅。我也不清楚如何使GCC自动化,所以我不必做两次。
首先,这个例子将变成一个库:
$ cat test.cxx
#include <string>
std::string foo __attribute__ ((visibility ("default")));
std::string bar __attribute__ ((visibility ("default")));
然后:
$ g++ -D_GLIBCXX_USE_CXX11_ABI=0 -c test.cxx -o test-v1.o
$ g++ -D_GLIBCXX_USE_CXX11_ABI=1 -c test.cxx -o test-v2.o
$ ar cr test.a test-v1.o test-v2.o
$ ranlib test.a
$ g++ -shared test-v1.o test-v2.o -o test.so
最后,看看我们得到了什么:
$ nm test.a
test-v1.o:
00000004 B bar
U __cxa_atexit
U __dso_handle
00000000 B foo
0000006c t _GLOBAL__sub_I_foo
00000000 t _Z41__static_initialization_and_destruction_0ii
U _ZNSsC1Ev
U _ZNSsD1Ev
test-v2.o:
U __cxa_atexit
U __dso_handle
0000006c t _GLOBAL__sub_I__Z3fooB5cxx11
00000018 B _Z3barB5cxx11
00000000 B _Z3fooB5cxx11
00000000 t _Z41__static_initialization_and_destruction_0ii
U _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC1Ev
U _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev
和
$ nm test.so
00002020 B bar
00002018 B __bss_start
00002018 b completed.7181
U __cxa_atexit@@GLIBC_2.1.3
w __cxa_finalize@@GLIBC_2.1.3
00000650 t deregister_tm_clones
000006e0 t __do_global_dtors_aux
00001ef4 t __do_global_dtors_aux_fini_array_entry
00002014 d __dso_handle
00001efc d _DYNAMIC
00002018 D _edata
00002054 B _end
0000087c T _fini
0000201c B foo
00000730 t frame_dummy
00001ee8 t __frame_dummy_init_array_entry
00000980 r __FRAME_END__
00002000 d _GLOBAL_OFFSET_TABLE_
000007dc t _GLOBAL__sub_I_foo
00000862 t _GLOBAL__sub_I__Z3fooB5cxx11
w __gmon_start__
000005e0 T _init
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
00001ef8 d __JCR_END__
00001ef8 d __JCR_LIST__
w _Jv_RegisterClasses
00000690 t register_tm_clones
00002018 d __TMC_END__
00000640 t __x86.get_pc_thunk.bx
0000076c t __x86.get_pc_thunk.dx
0000203c B _Z3barB5cxx11
00002024 B _Z3fooB5cxx11
00000770 t _Z41__static_initialization_and_destruction_0ii
000007f6 t _Z41__static_initialization_and_destruction_0ii
U _ZNSsC1Ev@@GLIBCXX_3.4
U _ZNSsD1Ev@@GLIBCXX_3.4
U _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC1Ev@@GLIBCXX_3.4.21
U _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev@@GLIBCXX_3.4.21