Как распространять Mac OS X с зависимыми библиотеками?

Question

У меня есть программа (в частности, моя запись для SO DevDays Countdown — соревнование по приложению), который опирается на несколько динамических библиотек, а именно libSDL, libSDL_ttf и другие.У меня эти библиотеки установлены под /opt/local/lib через MacPorts, и у многих людей они не будут установлены (а у некоторых они могут быть установлены, но не в этом месте).

Как мне распространить мою программу, чтобы люди, у которых не установлены эти библиотеки, могли запускать ее «из коробки»?Очевидно, мне придется распределить различные .dylib файлы, но этого недостаточно.Динамический загрузчик по-прежнему ищет библиотеки, установленные в тех местах, где они установлены.Есть ли способ заставить динамический загрузчик искать текущий каталог исполняемого файла, как это делает Windows с DLL?Людям не нужно изменять какие-либо переменные среды (например, DYLD_LIBRARY_PATH), так как опять же я хочу, чтобы это работало «из коробки».

Answer 1

Как вы упомянули, вы не используете Xcode, поэтому это немного сложно.Вот варианты в порядке моих предпочтений:

1. Переключитесь на Xcode.Используйте фреймворки.Библиотеки SDL уже доступны в виде фреймворков, и я видел более пары коммерческих игр с libsdl.framework внутри пакета приложения.

2. Используйте фреймворки, но сохраняйте свои Makefiles.Загрузите версии фреймворков ваших SDL-библиотек (или создайте их самостоятельно) и свяжите их с помощью флага компоновщика -framework.Распространяйте платформы вместе с вашим приложением или нет, и попросите пользователей поместить их либо в ~/Library/Frameworks, либо в /Library/Frameworks.Я бы не стал заморачиваться с установщиком для этого.

3. Статическая ссылка на SDL.В Makefile вам нужно будет указать путь к статическим библиотекам, а не использовать флаг -l, например, вы запускаете «ld blah blah /opt/local/lib/libsdl.a».Я не знаю, как указать -l предпочесть статические библиотеки общим, и поверьте мне, я посмотрел.

Answer 2

Основной подход к этому — отправить их в пакете .app.Затем вы измените место, где компоновщик ищет общие библиотеки, чтобы включить это.

Шаги:

1. Создайте новую фазу сборки файлов копирования для вашей цели, которая копирует эти файлы в каталог Frameworks пакета .app.

2. Измените параметр конфигурации сборки «Пути поиска пути», включив в него @executable_path/../Frameworks

Если вы создадите свой исполняемый файл с этими изменениями, а затем посмотрите, вы обнаружите, что dylibs существуют в Foo.app/Contents/Framework каталог и запуск otool -L Foo.app/Contents/MacOS/Foo для этих dylibs должен выдаваться и запись с префиксом @rpath.

Из этого Пост производителя какао:

В общем, @loader_path предпочтительнее @executable_path, как это
позволяет встроенным платформам работать как в исполняемом файле, так и в пакете,
плагин или подфреймворк.Единственный недостаток в том, что @loader_path
требуется 10.4 или новее.Если у вас версия 10.5 или новее, @rpath даже
лучше чем @loader_path.

Answer 3

Статически свяжите библиотеки.