静的ライブラリの依存関係ツリーでダイヤモンドの問題ですか？

Question

私には気になる問題があります。私は過去にそれに遭遇したと思いますが、私はインターネット上で同様の問題に関する情報を見つけることはできません。

は私が持っていると仮定します

• '共通の' ライブラリとそれの二つの異なる静的LIBS：libcommon1.2.aとlibcommon1.3.a。
• libcommon1.2.aを使用し、そこから新しい静的ライブラリを提供する「余分な共通ライブラリ」です。
• 最新の 'common'（libcommon1.3.a）​​と最新の 'extra-common'（ 'common'と 'extra-common'はアプリにリンクされています）を使用する最終アプリです。

「共通」v1.3とv1.2の間に新しいコンポーネントが追加されている場合は、すべて正常に動作するはずです。

'common' v1.3が 'extra-common'で使用されているAPIを変更した場合、おそらく私は余分な共通点を他のアプリケーションとリンクしている間、

'common' v1.3がv1.2と同じAPIを保持していて内部の一部が変更されている場合は、実行時にオブジェクトのサイズが変更されたり、vtableなどの変更によってクラッシュする可能性があります。 ）？

私はグーグル、いくつかのシナリオでランタイムクラッシュや記事へのリンクを引き起こす可能性があるいくつかの言葉を私に送ってもらえますか？そのような用語は "図書館の依存関係におけるダイヤモンド問題"のようなものですか？

私は何かに感謝します。

Answer 1

ここで説明している問題は、あなたの依存関係にダイヤモンド構造がないことです。libcommon1.2aに依存するライブラリ（余分なもの）を使用していますが、代わりにlibcommon1.3aにリンクしてください。それがなぜ安全でないかもしれないのかあなたはすでに理解しているように思えます。

あなたが探している用語はABI: application binary interfaceだと思います。呼び出し規約や構造体レイアウトなど、リンクされているモジュール間で一致させる必要のあるコンパイル済みコードの要素です。 ABIはAPIに似ていますが、ソースコードの代わりにコンパイルされたコードの互換性に関するものです。この2つは互いに独立しています：APIを破ることなくABIを破ることができます（たとえば、構造内のフィールドの名前を変更するなど）。APIを破ることなくABIを破ることができます（たとえば、データ型のサイズを変更する、構造）。

libcommon1.3aがlibcommon1.2aとABI互換でない場合は、そのライブラリで余分な共通ライブラリを安全に使用することはできません。 libcommon1.3aヘッダーを使用して、余分な共通コンポーネントを再コンパイルする必要があります。 （1.3aにもAPI互換性がない場合は、余分な部分も変更する必要があるかもしれません）。