次のシナリオを考えてみましょう: アプリケーションがサードパーティのライブラリ A にリンクしています。
A は MSVC 2008 を使用してビルドされ、C ランタイム ライブラリ v9.0 に静的にリンクされています (つまり、/MT でビルドされています)。
アプリケーションは MSVC 2005 を使用して構築され、A および (/MT を使用して) C ランタイム ライブラリ v8.0 に静的にリンクしています。
これには問題があります。たとえば、ランタイム ライブラリのバージョン間でヘッダーの型が変更された場合などです。
バージョン間でランタイム ライブラリ ヘッダーの互換性を維持するように注意していますか?それとも、静的にリンクされたすべてのライブラリが同じバージョンのランタイム ライブラリにリンクしていることを常に確認する必要がありますか?
問題になることはありません。各ライブラリは独自のランタイムにリンクし、ほとんどの場合、プロセス内の他のライブラリとは独立して機能します。この問題は、ライブラリ ABI の定義が不適切な場合に発生します。任意の種類のヒープ割り当てオブジェクトが 1 つのライブラリに割り当てられ、ライブラリ境界を越えて渡され、別のライブラリで「解放」された場合、割り当てに使用されたヒープ マネージャーからブロックを解放するために別のヒープ マネージャーが使用されているため、問題が発生します。それ。
c-runtime で定義された構造体、オブジェクト、またはエンティティは、異なるランタイム バージョンが使用されている可能性のある境界を越えて渡されるべきではありません。異なるランタイム。
ライブラリ API が生の型のみを使用し、渡されたポインタを free() しようとしたり、アプリケーション (または別のライブラリ) が free() することを期待する内部的に malloc() されたメモリへのポインタを渡したりしない限り、大丈夫なはず。
Cランタイムが混在している場合、「何でもうまくいかない」というFUDに陥りやすいですが、ライブラリと動的ライブラリ（.so / .dll / .dylib）は伝統的に多種多様に開発されてきたことを覚えておく必要があります言語の: asm、c、c++、fortran、pascal などで書かれたコードを、効果的な CPU 効率の良いバイナリ インターフェイスを介して通信できるようにします。
C が C にリンクされているときに突然パニックになるのはなぜですか?
これは非常に悪い計画です。避ける。2005 年にライブラリを再コンパイルするか、2008 年にアプリケーションをコンパイルします。
まったく良い考えではありません。ランタイムライブラリによって行われる仮定と、それらが特定のタイプを実装する方法を制御することはできません。これは、そうでないよりも、不潔な混乱を引き起こす可能性が高いです。