Подтвердить что ты не робот

Libz.dylib против libz.1.2.3.dylib против libz.1.2.5.dylib

Я спросил это в комментарии, но это похоже на проблему, которая заслуживает собственного вопроса.

У меня есть проект, который делится между тремя различными установками XCode и двумя различными установками SDK iOS. На данный момент объединение разработчиков не является вариантом.

Когда я установил бета-версию iOS 5 и XCode 4.2 libz.1.2.3.dylib, ее нигде не было. Я обнаружил, что ссылка на libz.1.2.5.dylib обрабатывается, но это несовместимо с другими активными установками XCode и iOS SDK.

Я исследовал это онлайн и обнаружил приведенное выше предложение и это предложение. Первое не работает для меня, и последнее заставляет меня нервничать.

Итак, какая разница между libz.dylib, libz.1.2.3.dylib и libz.1.2.5.dylib и могу ли я безопасно ссылаться на первую по всем установкам XCode и IOS SDK?

4b9b3361

Ответ 1

ОС часто включает в себя множество версий динамических библиотек. Они используются различными программами в зависимости от того, с какой библиотекой они были скомпилированы в момент компиляции, но когда вы компилируете, вы хотите связать с версией, которая соответствует установленным заголовкам, которые вы включаете/импортируете в свой исходный код.

libz.dylib будет ссылкой на ту же версию, что и ваши установленные заголовки.

Скажем, у вас есть 2 версии libXYZ.1.dylib и libXYZ.2.dylib, libXYZ.dylib - это ссылка на libXYZ.2.dylib и libXYZ.1.dylib - это устаревшая библиотека, которая также доступна в ОС для приложений, скомпилированных и распределенных до libXYZ.2.dylib был выпущен. libXYZ.1.dylib был включен в SDK, потому что могут существовать старые фреймворки, которые все еще хотят быть привязаны к старой версии.

Две версии могут иметь очень похожие интерфейсы в заголовке, поэтому вы не увидите никаких реальных различий при компиляции и запуске, но в будущих версиях старые версии могут быть удалены, а новые добавлены, что сделает ваш проект разбитым, когда сшивание.

Если я правильно понимаю, компоновщик будет разыменовывать ссылки на файлы, чтобы найти нужную версию и сохранить это имя dylib и динамически связать с ним, когда приложение запустится. Таким образом, libz.dylib не будет использоваться для пути (больше, чем во время компиляции).

Я вижу это в моей установке Xcode в 4.3 SDK

/Разработчик/.../SDKs/iPhoneOS4.3.sdk/USR/включать/zlib.h

/* zlib.h -- interface of the 'zlib' general purpose compression library
  version 1.2.3, July 18th, 2005

  Copyright (C) 1995-2005 Jean-loup Gailly and Mark Adler

libz.dylib

/Developer/.../SDKs/iPhoneOS4.3.sdk/usr/lib/libz.dylib -> libz.1.2.3.dylib

Ответ 2

Вы можете легко увидеть в поиске, как они работают. В XCode "Показать в Finder" - одна из библиотек. Теперь нажмите один раз на libz.dylib и "Получить информацию". Вы увидите, что "Оригинал":

/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk/usr/lib/libz.1.2.5.dylib (с XCode4.2 с iOS 5 SDK)

Теперь это символическая ссылка на версию 1.2.5. В будущем он обновится до последней версии 1.x.x. Вы можете просмотреть все различные версии таким образом.

Ответ 3

Просто ссылку с libz.dylib вместо конкретной версии, и компилятор свяжет доступную версию на установленном SDK. Ошибка компоновщика может возникнуть в случае ссылки на некоторую конкретную версию, которая недоступна в установленном SDK.

Ответ 4

Вы можете использовать libz.1.2.5.dylib вместо libz.1.2.3.dylib

Заменить libz.1.2.3.dylib ----- > libz.1.2.5.dylib