Почему зависимости фреймворка iOS не должны быть явно связаны с проектом статической библиотеки или фреймворка, если они используются для проекта приложения?
=============================================================================================================================================================

Зачем**exactly** когда я создаю проект статической библиотеки iOS или проект фреймворка в Xcode, мне не нужно связывать какие-либо фреймворки iOS SDK с проектом, чтобы использовать их заголовки и объекты - например, я могу`#import <AudioToolbox/AudioToolbox.h>` и поместите код AudioToolbox в статическую библиотеку или фреймворк, фактически не добавляя AudioToolbox в разделе «Связать двоичные файлы с библиотеками». в настройках сборки или при наличии его в файловом навигаторе, и проект будет создаваться без проблем, что не сработает в проекте приложения - но когда разработчик затем использует статическую библиотеку или продукт платформы в приложении, он делает нужно ли ссылаться на фреймворк, чтобы использовать одинаковые заголовки и объекты?

У меня есть смутное представление о том, почему это так, но мне действительно было бы интересно услышать от кого-то, кто знает наверняка.

`.o` файлы. Они "не" связаны " любым значимым образом; просто соединены вместе. До тех пор, пока вы не выполните реальный шаг ссылки, символы не будут разрешены.

По сути, нет никакой разницы между`.a` с вашим исполняемым файлом и копированием эквивалентного исходного кода в проект вашего исполняемого файла. Таким образом, нет необходимости связываться с какими-либо дополнительными платформами или библиотеками до этого времени.

Следующее упражнение может быть образовательным:

Создайте следующее`comptest.c`:

Посмотрите, что делает препроцессор:

Это удаляет`#include` и заменяет его содержимым ссылочного файла. Этот файл - то, что фактически видит компилятор.

Теперь посмотрим, что делает компилятор (я использую`>` синтаксис здесь и ниже, так что все параллельно`-E`):

Это сгенерированный язык ассемблера после предварительной обработки и компиляции. Теперь мы превращаем это в .o:

Теперь давайте посмотрим, что в этом .o:

Важные вещи здесь`_main` а также`_puts`. `_main` определяется в этом файле по адресу 0.`_puts` не определено Таким образом, кое-что, с чем мы связываемся, должно было обеспечить это Давайте попробуем связать без чего-либо:

(`_exit` неявный из среды выполнения C; на него нет прямой ссылки в .o)

Хорошо, теперь мы готовы собрать все это вместе. Мы будем явными:

Это говорит, чтобы связать вместе`comptest.o` и динамическая библиотека`libc`, Это обещает, что каждый символ, на который ссылаются, будет предоставлен одним из этих файлов. В полученном двоичном файле он отмечает, что он должен динамически загружать символы из`/usr/lib/libc.dylib` (это символическая ссылка на libSystem.B.dylib, которая сама по себе является «зонтичной платформой», а не правильной библиотекой, но в большинстве случаев это немного превосходит то, что вам нужно знать; вы можете сделать вид, что`puts()` находится в libSystem):

Если вы свяжетесь со статической библиотекой, это будет идентично перечислению всех файлов .o, включенных в нее, в командной строке.

Обратите внимание, что на этапе связывания у нас просто есть файлы .o и .dylib (.a - это просто пакет .o). Нет .c файлов, нет .h файлов, нет .s файлов, нет исходного кода. Просто объектные файлы, которые требуют разрешения символов. Вот почему заголовочные файлы здесь не имеют значения, но имеют значение при компиляции.