次のリンクに関して: http://www.archlinux.org/news/libpnglibtiff-rebuilds-move-from-testing/
ライブラリの 1 つが更新された後に、プログラムを再構築する必要がある理由を説明してもらえますか?
「メイン」ファイルがまったく変更されていないので、それはどのように意味がありますか?
次のリンクに関して: http://www.archlinux.org/news/libpnglibtiff-rebuilds-move-from-testing/
ライブラリの 1 つが更新された後に、プログラムを再構築する必要がある理由を説明してもらえますか?
「メイン」ファイルがまったく変更されていないので、それはどのように意味がありますか?
関連する関数の署名が変更されていない場合、プログラムの「再構築」は、オブジェクト ファイルを再度リンクする必要があることを意味します。それらを再度コンパイルする必要はありません。
API は、ライブラリ内のパブリック関数へのインターフェイスを記述する契約です。コンパイラがコードを生成するとき、各関数に渡す変数の型と順序を知る必要があります。また、関数から返されるデータのサイズと形式を認識できるように、戻り値の型も認識する必要があります。コードがコンパイルされると、ライブラリ関数のアドレスは、「ライブラリの先頭に 140 バイトを加えたもの」として表される場合があります。コンパイラは絶対アドレスを知らないので、単にライブラリの先頭からのオフセットを指定します。
ただし、ライブラリ内では、関数の内容(つまり実装) が変更される場合があります。その場合、コードの長さが変わることがありますので、関数のアドレスがずれることがあります。各関数のエントリ ポイントがどこにあるかを理解し、それらのアドレスをオブジェクト コードに入力して実行可能ファイルを作成するのは、リンカーの仕事です。
一方、ライブラリ内のデータ構造が変更され、ライブラリが呼び出し側でメモリを管理する必要がある場合 (悪い習慣ですが、残念ながら一般的です)、変更を反映できるようにコードを再コンパイルする必要があります。たとえばmalloc(sizeof(dataStructure))
、サイズが 2 倍になったライブラリ データ構造にメモリを割り当てるためにコードを使用する場合、sizeof(dataStructure)
値が大きくなるため、コードを再コンパイルする必要があります。
互換性には、API と ABI の 2 種類があります。
API の互換性は、他のプログラムが依存する可能性がある関数とデータ構造に関するものです。たとえば、バージョン 0.1 の libfoo で「hello_world()」という API 関数が定義されていて、バージョン 0.2 でそれが削除された場合、「hello_world()」に依存するすべてのプログラムは、新しいバージョンの libfoo で動作するように更新する必要があります。
ABI 互換性とは、関数、特にデータ構造がバイナリでどのように表現されるかという前提に関するものです。たとえば、libfoo 0.1 がrecipe
「instructions」と「ingredients」の 2 つのフィールドを持つデータ構造も定義し、libfoo 0.2 が「ingredients」フィールドの前に「測定値」を導入した場合、libfoo 0.1 のレシピに基づくプログラムは再コンパイルする必要があります。 「成分」フィールドは、libfoo.so バイナリの 0.2 バージョンでは異なる位置にある可能性があります。
「ライブラリ」とは何ですか?
「ライブラリ」がバイナリのみの場合(たとえば、動的にリンクされたライブラリ、別名「.dll」、「。dylib」、「。so」、または静的にリンクされたライブラリ、別名「.lib」、「。a」)、再コンパイルする必要はありません。再リンクで十分です(特別な場合でも回避できます)。
一方、ライブラリは多くの場合、バイナリオブジェクトだけで構成されているわけではありません。たとえば、ヘッダーファイルにはインライン(またはマクロ)ロジックが含まれている場合があります。その場合、再リンクだけでは不十分であり、最新バージョンのライブラリを使用するには、再コンパイルが必要になる場合があります。