I have a Ubuntu 13.04 system with the latest SVN versions of Boost C ++ libraries. The Boost installation was built using the original gcc version for the system, v4.7.3. I use Boost quite widely, and it works great when compiling with gcc ; I used many of them, including Boost.Thread (which I will discuss in more detail) without any problems.
My problem arises if I try to create a program using the Intel C ++ compiler (I personally used several different versions in the v13.x series) that reference the installed Boost libraries. When I do this, I get a segmentation error immediately after starting the program; it appears during the static initialization of the Boost.Thread library. Here is a simple sample program:
#include <boost/version.hpp> #include <boost/thread.hpp> int main() { boost::this_thread::sleep(boost::posix_time::seconds(1)); }
I will 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 an almost immediate segfault. Via gdb stack trace from the segfault point is as follows:
Not very enlightening, but it clearly dies during the initialization of libboost_thread.so . If I rebuild Boost, including debugging symbols, I get a slightly better image:
#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 ?? ()
I don’t understand which static / global object is causing the problem, so I'm not sure how to do this. I duplicated this behavior using several versions of Boost and several different versions of the Intel C ++ compiler in the v13.x series, which is the only version that I have access to at the moment. I tried every permutation of the compiler (i.e. I built Boost with both gcc and icpc , and I also created a test application with both); the only permutation that fails is where Boost is built with gcc and my test application is built using icpc . In each other case, the test application runs successfully.
With that said, you can lead to the obvious answer:
- Why not just rebuild Boost with
icpc and name it day? . This approach would seem to be effective, given my experiments, but I have clients who like to use icpc to build my software. The same clients are likely to have the Linux Boost package installed; they have no control over the build environment that was used to create this package (and, in all likelihood, it was compiled using gcc ). Therefore, if it is possible to support such a configuration of a mixed compiler, this would be optimal.
Does anyone have any recommendations on how I can solve this problem with static initialization?