gcc組み込みブーストをインテルC++コンパイル済みプログラムにリンクするときの静的初期化中のSegfault

Question

最新のSVNバージョンのBoost C++ライブラリがインストールされたUbuntu 13.04システムがあります。 Boostのインストールは、システム固有のgccバージョン、v4.7.3を使用して行われました。私はBoostをきわめて広範囲に使用し、gccを使用してコンパイルすると非常にうまく動作します。私はBoost.Thread（これについては以下で詳しく説明します）を含め、何も問題なく使用しています。

私の問題は、インストールされているBoostライブラリとリンクするIntel 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を経て、セグメンテーション違反の点からスタックトレースは次のとおりです。

#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の初期化中に死にました。私はデバッグシンボルを含めブーストを再構築する場合、その後、私は少し良く画像取得：

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

をそれは、オブジェクトが、問題が発生する原因となっている静的/グローバル私には不明だので、私は続行するかどうかはわかりません。私は、この動作をいくつかのBoostバージョンといくつかの異なるバージョンのIntel C++コンパイラをv13.xシリーズで使用しています。これは、私が現在アクセスしている唯一のリリースです。私はすべてのコンパイラ順列を試しました（すなわち、私はgccとicpcの両方でBoostをビルドしました。私は両方ともテストアプリケーションを構築しました）。 Boostがgccで構築されており、私のテストアプリケーションがicpcを使って構築されている場所だけが失敗します。それ以外の場合は、テストアプリケーションが正常に実行されます。

• 理由だけicpcを使用してブーストを再構築しないと一日それを呼び出す：？それ言った、あなたは明白な答えにつながったかもしれないと

  私の実験によれば、そのアプローチは効果的だと思われますが、icpcを使用して私のソフトウェアを構築したいと思う顧客がいます。これらの同じ顧客には、Linuxディストリビューションで提供されるBoostパッケージがインストールされている可能性があります。そのパッケージを生成するために使用されたビルド環境を制御することはありません（とにかく、gccを使用してコンパイルされていました）。したがって、このような混合コンパイラ構成をサポートすることが可能な場合は、最適となります。

この静的初期化の問題にどのように対処するかについてお勧めしますか？あなたは、Boostライブラリを構築し、それを取り除くかicpcに-gxx-name /usr/bin/g++を渡すために使用したものよりも、あなたのPATHで異なるg++を持っている場合は

Answer 1

これは、ロングショットですが、...。 （インテル®コンパイラーは、あなたが使用していると思うGCCのバージョンに適応します。-gxx-nameは強制的に問題を引き起こします。）

これはおそらく役に立ちませんでした。

Ubuntu 13.04は、Intel Composer XE 2013 SP1より前はサポートされていません。コンパイラのバージョン14.0.0。 "System Requirements" section of the Release Notesを参照し、same section for the last 13.x releaseと比較してください。

インテルは間違いなくGCCとのリンク互換性を目指しています。サポートされているバージョンのLinuxをクリーンインストールしてこの問題を再現できる場合は、サポートチケットを提出して修正する必要があります。