Segfault during static initialization when linking gcc-built Boost into an Intel C++-compiled program

Question

I have an Ubuntu 13.04 system with the latest SVN version of the Boost C++ libraries installed. The Boost installation was built using the system's native gcc version, v4.7.3. I use Boost pretty extensively, and it works very well when I compile using gcc; I have used many of them, including Boost.Thread (which I will talk about more below), without any issues.

My problem occurs if I try to build a program using the Intel C++ compiler (I've personally used a few different versions in the v13.x series) that link with the installed Boost libraries. When I do so, I get a segmentation fault immediately after program startup; it appears to occur during static initialization of the Boost.Thread library. Here's a simple example program:

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

int main()
{
    boost::this_thread::sleep(boost::posix_time::seconds(1));
}

I compile it using Intel C++:

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

As I said, when I run the resulting program, I get a near-immediate segfault. Via gdb, the stack trace from the point of the segfault is as follows:

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

Not very enlightening, but it's clearly dying during the initialization of libboost_thread.so. If I rebuild Boost including debug symbols, then I get a slightly better picture:

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

It's unclear to me what static/global object is causing the problem to occur, so I'm not sure how to proceed. I have duplicated this behavior using a number of Boost versions and a few different versions of the Intel C++ compiler in the v13.x series, which is the only release that I have access to at the moment. I have tried every compiler permutation (i.e. I have built Boost with both gcc and icpc and I've built my test application with both also); the only permutation that fails is where Boost is built with gcc and my test application is built using icpc. In every other case, the test application runs successfully.

With that said, you might be led to the obvious answer:

• Why not just rebuild Boost using icpc and call it a day? That approach would seem to be effective, given my experimentation, but I have customers who like to use icpc to build my software. Those same customers are likely to have a Linux-distro-provided Boost package installed; they do not have any control over the build environment that was used to generate that package (and, in all likelihood, it was compiled using gcc anyway). Therefore, if it is possible to support such a mixed-compiler configuration, that would be optimal.

Does anyone have any recommendations as to how I might address this static initialization issue?

Answer 1

This is a long shot, but... If you have a different g++ in your PATH than the one used to build the Boost libraries, get rid of it or pass -gxx-name /usr/bin/g++ to icpc. (The Intel compiler adapts itself to the version of GCC it thinks you are using. -gxx-name lets you force the issue.)

OK that probably did not help.

Ubuntu 13.04 is not supported prior to Intel Composer XE 2013 SP1, aka. compiler version 14.0.0. See the "System Requirements" section of the Release Notes and compare it to the same section for the last 13.x release.

Intel definitely aims for link compatibility with GCC. If you can reproduce this problem on a clean install of a supported version of Linux, you should be able to submit a support ticket and get it fixed.