私は現在ライブラリを作成しており、GCC 4.1.2から4.5.2(最新リリース)のGCCへの移行を検討しています。コードを静的ライブラリにコンパイルする場合、コンパイラの互換性(明らかに同じOS上で)はクライアントにとって問題ではないと想定できますか?
編集 さらに明確にするために:gcc 4.5.2でコンパイルされた静的にリンクされたライブラリをクライアントに提供する場合、使用する必要のあるコンパイラとバージョンに関して、このライブラリのユーザーにどのような制限がありますか?
私は現在ライブラリを作成しており、GCC 4.1.2から4.5.2(最新リリース)のGCCへの移行を検討しています。コードを静的ライブラリにコンパイルする場合、コンパイラの互換性(明らかに同じOS上で)はクライアントにとって問題ではないと想定できますか?
編集 さらに明確にするために:gcc 4.5.2でコンパイルされた静的にリンクされたライブラリをクライアントに提供する場合、使用する必要のあるコンパイラとバージョンに関して、このライブラリのユーザーにどのような制限がありますか?
http://gcc.gnu.org/bugs/#nonbugsからの私の質問に答えると私が信じているこれに出くわしたばかりです:
ABIの変更C++アプリケーションバイナリインターフェイス(ABI)は、2つのコンポーネントで構成されています。1つは、クラスの要素のレイアウト方法、関数の呼び出し方法、関数名のマングル方法などを定義します。2番目の部分では、libstdc++のオブジェクトの内部を扱います。変更されないABIを目指していますが、これまでのところ、メジャーリリースごとに変更する必要がありました。コンパイラを別のメジャーリリースに変更する場合は、C++コードを含むすべてのライブラリを再コンパイルする必要があります。そうしないと、リンカエラーやプログラムの誤動作が発生するリスクがあります。一部のJavaサポートライブラリにはC++コードも含まれているため、安全のためにすべてのライブラリを再コンパイルすることをお勧めします。同じバージョンのコンパイラのバグ修正リリースに変更した場合は、再コンパイルする必要はありません。バグ修正リリースでは、ABIの変更を回避するように注意しています。GCCマニュアルの互換性のセクションも参照してください。
備考:メジャーリリースは、2部構成または3部構成のバージョン番号の1番目または2番目のコンポーネントへの変更によって指定されます。マイナー(バグ修正)リリースは、3番目のコンポーネントへの変更によってのみ指定されます。したがって、GCC 3.2および3.3はメジャーリリースであり、3.3.1および3.3.2はGCC3.3のバグ修正リリースです。3.4シリーズでは、新しい命名スキームを導入しています。このシリーズの最初のリリースは、3.4ではなく3.4.0です。
これから、私が理解しているように、クライアントが私のライブラリをメジャーリリースの互換性のあるバージョンのgccにリンクしていることを確認する必要があります。
静的ライブラリと動的ライブラリのどちらを提供するかは実際には問題ではありません。ユーザーは、互換性のあるコンパイラ/リンカーを使用してリンクする必要があります。通常、GCCがABIを変更すると、古いABIを使用するように設定できるスイッチが提供されます。3.xから4.xに移行したとき、さらには4.xシリーズ内のいくつかのリリースでさえ、彼らがそれを行ったことを私は知っています。