私はアプリケーションをライブラリ部分とライブラリとリンクするアプリケーションに分けています。ライブラリは を使用するため、 とフレームワークAFNetworkingが必要です。これらは、ビルド プロセスとライブラリ ビルドに適切に追加されます。SystemConfigurationMobileCoreServices
適切にビルドし、リンク エラーを表示しないために、アプリケーション パーツに同じフレームワークを追加する必要があるのはなぜですか?
ライブラリとの連携だけじゃ物足りない?
私はアプリケーションをライブラリ部分とライブラリとリンクするアプリケーションに分けています。ライブラリは を使用するため、 とフレームワークAFNetworkingが必要です。これらは、ビルド プロセスとライブラリ ビルドに適切に追加されます。SystemConfigurationMobileCoreServices
適切にビルドし、リンク エラーを表示しないために、アプリケーション パーツに同じフレームワークを追加する必要があるのはなぜですか?
ライブラリとの連携だけじゃ物足りない?
ライブラリは静的ライブラリであると想定しています。インクルード ファイルにアクセスするために静的ライブラリをビルドするときに、フレームワークを追加するだけです。フレームワークとリンクしていません。これは、ビルド時にスタティック ライブラリがリンクされていないためです。これは単にオブジェクト ファイルの集まりです。コマンド ラインからこれを試して、オブジェクト ファイルを一覧表示します。
$ ar t /path/to/my/library.a
静的ライブラリがアプリ バイナリにリンクされている場合、静的ライブラリ内のオブジェクト ファイルがアプリ バイナリ ソース ツリーの一部であるかのように、両方のライブラリとフレームワークを提供する必要があります。
静的ライブラリをオブジェクト ファイルの単純なコレクションと考えてください。それは理解できるはずです。
Apple の iOS フレームワークには、動的共有ライブラリが含まれています。私の知る限り、アプリが起動すると、プロセスが作成され、プロセスがリンクされている動的共有ライブラリがメモリにロードされます。動的共有ライブラリが (他のアプリ プロセス用に) 既にメモリに読み込まれている場合、それらはアプリ プロセスと共有されます。これは、プロセス アクティビティごとです。
静的ライブラリはアプリケーション バイナリ自体の一部としてリンクされ、別のプロセスを作成しないため、静的ライブラリがリンクするフレームワークをロードするようにランタイムに通知する必要があります。したがって、静的ライブラリで使用されるフレームワークをアプリケーションにも追加することは論理的です。