Как создать рабочую среду с файлами dylib в Xcode 4

Ответ 1

Я думаю, что вы неправильно понимаете сообщение об ошибке.

A .framework работает как динамическая библиотека, но не будет никакого загружаемого объектного файла Mach-O с фактическим расширением имени файла .dylib внутри папки .framework.

Есть несколько причин, по которым вы можете получить это сообщение об ошибке из dyld, загрузчика динамической библиотеки ссылок, во время выполнения. Во-первых, вы забыли скопировать .frameworks во встроенный пакет приложений во время процесса сборки. Хотя их можно скопировать в любое место внутри пакета приложений, традиционное место находится в AppName.app/Contents/Frameworks/. Если вы еще этого не сделали, выберите "Проект" > "Новая фаза сборки" > "Новая фаза сборки файлов копирования". Измените всплывающее окно назначения на фреймворки, как на изображении ниже.

Затем вы перетащите значок фреймворка в папку, чтобы он копировался в процессе сборки.

Вторая и более вероятная причина, по которой инфраструктура не может быть найдена во время выполнения, заключается в том, что вы не указали пути поиска пути к основному исполняемому файлу. (Это необходимо, потому что, как мы видели из вашего сообщения об ошибке, ваша структура была построена с использованием более нового стиля @rpath/ style install name (@rpath/add.framework/Versions/A/add), а не более старых стилей @executable_path/ или @loader_path/).

При копировании пользовательских фреймворков в указанное выше местоположение вы должны добавить запись пути поиска пути @loader_path/../Frameworks, как показано на рисунке ниже:

Следующая выдержка, объясняющая, как динамические библиотеки находятся во время выполнения, находится из manpage dyld:

ЗАГРУЗКА ДИНАМИЧЕСКОЙ БИБЛИОТЕКИ

В отличие от многих других операционных систем, Дарвин не находит зависимых динамических библиотек через их имя файла листа. Вместо этого используется полный путь к каждому dylib (например, /usr/lib/libSystem.B.dylib). Но бывают случаи, когда путь не подходит; например, может потребоваться, чтобы ваши двоичные файлы были устанавливаемый в любом месте на диске. Чтобы поддержать это, есть три @xxx/, которые могут использоваться как префикс пути. Во время выполнения dyldзаменяет динамически сгенерированный путь для префикса @xxx/.

@executable_path/

Эта переменная заменяется на путь к каталогу содержащий основной исполняемый файл для процесса. Это полезно для      загрузка dylibs/frameworks, встроенных в каталог .app. Если главный исполняемый файл находится в /some/path/My.app/Contents/MacOS/My     и файл dylib рамки находится на
/some/path/My.app/Contents/Frameworks/Foo.framework/Versions/A/Fooто путь загрузки структуры может быть закодирован как @executable_path/../Frameworks/Foo.framework/Versions/A/Foo и каталог .app может      перемещаться в файловой системе и dyld будет по-прежнему в состоянии для загрузки встроенной инфраструктуры.

@loader_path/

Эта переменная заменяется на путь к каталогу содержащий двоичный файл mach-o, который содержит команду загрузки, используя       @loader_path. Таким образом, в каждом бинарнике @loader_path разрешается другой путь, тогда как @executable_path всегда разрешает      тот же путь. @loader_path полезен как путь загрузки для framework/dylib, встроенный в плагин, если конечная файловая система местоположение неизвестного плагина (так что абсолютные пути не могут быть использованы)      или если подключаемый модуль используется несколькими приложениями (так @executable_path не может использоваться). Если подключаемый файл mach-o находится в      /some/path/Myfilter.plugin/Contents/MacOS/Myfilter и фреймворк dylib находится в /some/path/Myfilter.plugin/Contents/Frameworks/Foo.framework/Versions/A/Fooзатем путь загрузки структуры      могут быть закодированы как @loader_path/../Frameworks/Foo.framework/Versions/A/Foo и Каталог Myfilter.plugin может быть      перемещается в файловой системе, а dyld все равно сможет загрузите встроенную инфраструктуру.

@rpath/

Dyld поддерживает текущий стек путей, называемый путём запуска      список. Когда встречается @rpath, он заменяется каждым      путь в списке путей запуска до загружаемого dylib, если он найден.      стека путей запуска создается из команд загрузки LC_RPATH в      которые приводят к текущей нагрузке dylib. Ты можешь      добавьте команду загрузки LC_RPATH к изображению с помощью опции -rpath     до ld (1). Вы даже можете добавить путь команды загрузки LC_RPATH, который      начинается с @loader_path/, и он будет запускать путь на ходу      стека пути относительно изображения, содержащего LC_RPATH.      Использование @rpath наиболее полезно, если у вас есть комплекс структуру каталогов программ и dylib, которые могут быть установлены      в любом месте, но сохраняйте свои относительные позиции. Этот сценарий      может быть реализована с использованием @loader_path, но каждый клиент      dylib может потребоваться другой путь загрузки, поскольку его относительный      положение в файловой системе отличается. Использование @rpath     вводит уровень косвенности, который упрощает вещи. Вы      выберите местоположение в структуре вашего каталога как опорную точку.      Затем каждый dylib получает путь установки, который начинается с @rpath и      это путь к dylib относительно опорной точки. Каждый основной      исполняемый файл связан с -rpath @loader_path/zzz, где zzz     путь от исполняемого файла до точки привязки. Во время выполнения      dyld устанавливает путь запуска как опорную точку, тогда каждый dylib      найдено относительно точки привязки.