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

时间:2013-09-21 01:16:36

标签: 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));
}

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

icpc test.cc -lboost_thread -lboost_system -I/path/to/boost/inc/dir -L/path/to/boost/lib/dir

正如我所说,当我运行生成的程序时,我会立即得到一个段落错误。通过gdb,来自segfault点的堆栈跟踪如下:

#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 ?? ()

不是很有启发性,但在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 ?? ()

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

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

  • 为什么不使用icpc重建Boost并将其称为一天?根据我的实验,这种方法似乎很有效,但我有客户喜欢使用{{1构建我的软件。那些相同的客户可能会安装Linux-Distro提供的Boost软件包;他们无法控制用于生成该包的构建环境(并且很可能,它仍然使用icpc进行编译)。因此,如果可以支持这种混合编译器配置,那将是最佳的。

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

1 个答案:

答案 0 :(得分:4)

这是一个很长的镜头,但是......如果g++中的PATH与用于构建Boost库的-gxx-name /usr/bin/g++不同,请删除它或通过icpc-gxx-name。 (英特尔编译器适应它认为您正在使用的GCC版本。{{1}}可以强制解决问题。)

好吧,这可能没有用。

英特尔Composer XE 2013 SP1之前不支持Ubuntu 13.04。编译器版本14.0.0。请参阅"System Requirements" section of the Release Notes并将其与same section for the last 13.x release进行比较。

英特尔绝对的目标是与GCC的链接兼容性。如果您可以在支持的Linux版本的干净安装上重现此问题,则应该能够提交支持服务单并将其修复。