在将gcc构建的Boost链接到Intel C++编译的程序时,静态初始化期间的Segfault

Jas*_*n R 6 c++ gcc boost icc

我有一个Ubuntu 13.04系统,安装了最新的SVN版本的Boost C++库.Boost安装是使用系统的本机gcc版本v4.7.3构建的.我使用Boost非常广泛,当我使用编译时它非常好用gcc; 我已经使用了很多,包括Boost.Thread(我将在下面详细讨论),没有任何问题.

如果我尝试使用与已安装的Boost库链接的英特尔C++编译器(我个人在v13.x系列中使用了几个不同版本)来构建程序,则会出现问题.当我这样做时,程序启动后立即出现分段故障; 它似乎发生在Boost.Thread库的静态初始化期间.这是一个简单的示例程序:

#include <boost/version.hpp>
#include <boost/thread.hpp>

int main()
{
    boost::this_thread::sleep(boost::posix_time::seconds(1));
}
Run Code Online (Sandbox Code Playgroud)

我使用英特尔C++编译它:

icpc test.cc -lboost_thread -lboost_system -I/path/to/boost/inc/dir -L/path/to/boost/lib/dir
Run Code Online (Sandbox Code Playgroud)

正如我所说,当我运行生成的程序时,我得到了近乎立即的段错误.通过gdb,段错误点的堆栈跟踪如下:

#0  0x00007ffff79b6351 in boost::exception_ptr boost::exception_detail::get_static_exception_object<boost::exception_detail::bad_exception_>() () from ./libboost_thread.so.1.55.0
#1  0x00007ffff79b02e1 in _GLOBAL__sub_I_thread.cpp () from ./libboost_thread.so.1.55.0
#2  0x00007ffff7de9876 in call_init (l=l@entry=0x7ffff7ff9a10, argc=argc@entry=1, 
    argv=argv@entry=0x7fffffffe0b8, env=env@entry=0x7fffffffe0c8) at dl-init.c:84
#3  0x00007ffff7de9930 in call_init (env=<optimized out>, argv=<optimized out>, 
    argc=<optimized out>, l=0x7ffff7ff9a10) at dl-init.c:55
#4  _dl_init (main_map=0x7ffff7ffe268, argc=1, argv=0x7fffffffe0b8, env=0x7fffffffe0c8)
    at dl-init.c:133
#5  0x00007ffff7ddb68a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#6  0x0000000000000001 in ?? ()
#7  0x00007fffffffe391 in ?? ()
#8  0x0000000000000000 in ?? ()
Run Code Online (Sandbox Code Playgroud)

不是很有启发性,但它在初始化期间显然已经死亡libboost_thread.so.如果我重建Boost包括调试符号,那么我得到一个更好的图片:

#0  shared_count (r=..., this=0x7ffff7bbc5f8 <boost::exception_ptr boost::exception_detail::get_static_exception_object<boost::exception_detail::bad_exception_>()::ep+8>)
    at ./boost/smart_ptr/shared_ptr.hpp:328
#1  shared_ptr (this=0x7ffff7bbc5f0 <boost::exception_ptr boost::exception_detail::get_static_exception_object<boost::exception_detail::bad_exception_>()::ep>) at ./boost/smart_ptr/shared_ptr.hpp:328
#2  exception_ptr (ptr=..., this=0x7ffff7bbc5f0 <boost::exception_ptr boost::exception_detail::get_static_exception_object<boost::exception_detail::bad_exception_>()::ep>)
    at ./boost/exception/detail/exception_ptr.hpp:53
#3  boost::exception_detail::get_static_exception_object<boost::exception_detail::bad_exception_> () at ./boost/exception/detail/exception_ptr.hpp:130
#4  0x00007ffff79b02e1 in __static_initialization_and_destruction_0 (__initialize_p=<optimized out>, __priority=<optimized out>) at ./boost/exception/detail/exception_ptr.hpp:143
#5  _GLOBAL__sub_I_thread.cpp(void) () at libs/thread/src/pthread/thread.cpp:767
#6  0x00007ffff7de9876 in call_init (l=l@entry=0x7ffff7ff9a10, argc=argc@entry=1, argv=argv@entry=0x7fffffffe0b8, env=env@entry=0x7fffffffe0c8) at dl-init.c:84
#7  0x00007ffff7de9930 in call_init (env=<optimized out>, argv=<optimized out>, argc=<optimized out>, l=0x7ffff7ff9a10) at dl-init.c:55
#8  _dl_init (main_map=0x7ffff7ffe268, argc=1, argv=0x7fffffffe0b8, env=0x7fffffffe0c8) at dl-init.c:133
#9  0x00007ffff7ddb68a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#10 0x0000000000000001 in ?? ()
#11 0x00007fffffffe391 in ?? ()
#12 0x0000000000000000 in ?? ()
Run Code Online (Sandbox Code Playgroud)

我不清楚什么静态/全局对象导致问题发生,所以我不知道如何继续.我在v13.x系列中使用了许多Boost版本和几个不同版本的英特尔C++编译器重复了这种行为,这是我目前唯一可以访问的版本.我想尽编译置换(即我所建的升压既gccicpc我已经建立了我的测试应用程序既亦可); 唯一失败的排列是Boost构建的地方gcc,我的测试应用程序是使用构建的icpc.在所有其他情况下,测试应用程序成功运行.

话虽如此,你可能会得到明显的答案:

  • 为什么不重新使用Boost icpc并将其称为一天?考虑到我的实验,这种方法似乎是有效的,但我有客户喜欢icpc用来构建我的软件.那些相同的客户可能会安装Linux-Distro提供的Boost软件包; 他们对用于生成该包的构建环境没有任何控制权(并且很可能gcc无论如何都是使用它编译的).因此,如果可以支持这种混合编译器配置,那将是最佳的.

有没有人对如何解决这个静态初始化问题有任何建议?

Nem*_*emo 4

这是一个不太可能的尝试,但是...如果您的g++PATH与用于构建 Boost 库的库不同,请将其删除或传递-gxx-name /usr/bin/g++icpc. (英特尔编译器会自行适应它认为您正在使用的 GCC 版本。-gxx-name让您强制解决该问题。)

好吧,这可能没有帮助。

Intel Composer XE 2013 SP1 之前的版本不支持 Ubuntu 13.04。编译器版本14.0.0。请参阅发行说明的“系统要求”部分,并将其与最新 13.x 版本的同一部分进行比较。

Intel 的目标绝对是与 GCC 的链接兼容性。如果您可以在受支持的 Linux 版本的全新安装上重现此问题,您应该能够提交支持票证并修复该问题。

  • @JasonR:我会的。请注意,第一个阅读您报告的人将是“1 级”无人机,因此您的目标是让他们相信这是一个真正的错误,这样他们就会将您推上链条。保持简短,提供最小的测试用例,并给出非常字面的“重现步骤”。Ubuntu 12.04 非常好,因为它是 LTS 版本。祝你好运 :-)。 (2认同)