Как поделиться вторичным dylib внутри фреймворка - PullRequest
Новая
       19

Как поделиться вторичным dylib внутри фреймворка

0 голосов
/ 18 ноября 2018

Возможно ли опубликовать / поделиться вторичным dylib внутри фреймворка (xxx.framework / Library / *. Dylib) с внешним (видимым, когда ссылки на внешние приложения)?

//

Я пытаюсь инкапсулировать несколько libavXXX.dylib (из проекта ffmpeg) в одну платформу (MElibrary.framework). В настоящее время я застрял в «не могу сделать его видимым - вторичные файлы dylib внутри Framework - для компоновщика при ссылке на Framework». Это выполнимый план с пакетом Framework?

Проблема в чем я сейчас застрял

  • Когда тестовое приложение связывается с моим фреймворком, сборка не удалась. Линкер (ld) не находит мои вторичные файлы dylib в каталоге framework / Libraries /.

Что я делал до сих пор

  • Подготовка MElibrary.framework / Версии / A / Библиотеки / (и его символическая ссылка как MElibrary.framework / Библиотеки)
  • Поместите каждый libavxxx.dylib (и его символические ссылки) в MElibrary.framework / Libraries /
  • Обновите пути к dylib id / lib, используя имя_установки_tool, в @ rpath / MElibrary.framework / Versions / A / Libraries / xxx.dylib
  • Поместите заголовочные файлы libavxxx в xxx.framework / Headers / include / libavxxx / xxx.h
  • Включить основные заголовочные файлы, такие как #include "include / libavxxx / xxx.h", в MElibrary.h
  • Создайте module.modulemap и определите вторичные заголовки dylib как подмодули
  • Связь вторичного dylib с самим MElibrary
  • Подтверждает с помощью otool -LX или otool -DX, что сам MElibrary и все файлы dylib имеют пути @ rpath / MElibrary.framework / Versions / A / ....
  • Попробуйте создать тестовое приложение со связанной структурой
  • Подтвержденный шаг компиляции выполняется с использованием функций libavxxx
  • Но сборка не удалась, потому что шаг ссылки каждый раз не удавался
  • Я думаю, это потому, что вторичные файлы dylib не видны компоновщиком

Сообщения об ошибках 

Undefined symbols for architecture x86_64:
  "_avcodec_register_all", referenced from:
      -[ViewController viewDidLoad] in ViewController.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Структура моего фреймворка следующая: 

MElibrary.framework
 + Headers (symlink)
 + Libraries (symlink)
 + MElibrary (symlink)
 + Modules (symlink)
 + Resources (symlink)
 + Versions
   + Current (symlink)
   + A
     + Headers
       + MElibrary.h
       + include
         + libavcodec/....h
         + :
     + Libraries
       + libavcodec.xxx.dylib .... I want these dylib visible when framework is linked
       + :
     + MElibrary .... framework dylib itself (dummy - no code)
     + Modules
       + module.modulemap
     + Resources
       + Info.plist

Обновление

Siguza, спасибо за ваш комментарий. Я работал с «Xcode10.1 / Настройки сборки / Повторно экспортированные имена библиотек», чтобы проверить функциональность, но пока безуспешно. 

ld: file not found: @rpath/MElibrary.framework/Versions/A/Libraries/libavcodec.58.dylib for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Ссылка комментарий boonerhasit"Отсюда кажется, что dyld не разрешает @rpath для команды LC_REEXPORT_DYLIB, только команды LC_LOAD * _DYLIB.",

мой фреймворк с otool -l MElibrary.framework / MElibrary показывает: 

Load command 9
          cmd LC_REEXPORT_DYLIB
      cmdsize 96
         name @rpath/MElibrary.framework/Versions/A/Libraries/libavcodec.58.dylib (offset 24)
   time stamp 2 Thu Jan  1 09:00:02 1970
      current version 58.33.102
compatibility version 58.0.0

Заключение (не удалось)

После нескольких испытаний я пришел к выводу, что мой первоначальный план неосуществим.

Линкер не понимает реэкспортированный dylib на основе @rpath. Я не уверен, хотя думаю, что это было бы из соображений безопасности.

  • Сама Framework может иметь вторичные dylib (s) внутри Framework, хотя она предназначена только для внутреннего использования. Они находятся внутри Framework, поэтому должны иметь относительный путь "@rpath". dylib на основе @rpath не поддерживает реэкспорт.
  • Если вам нужно экспортировать символы вторичных dylib (ов), вы можете использовать опцию ld -reexport-l (например, -reexport-lavcodec), но она не работает так, как задумано в этом случае.
  • Экспортируемая библиотека определяется в команде LC_REEXPORT_DYLIB. Вы можете подтвердить, что otool -l показывает экспортированные пути вторичной библиотеки. Но сам компоновщик ld не понимает слово "@rpath", и компоновщик всегда не может связать вашу инфраструктуру из-за "ld: файл не найден: @rpath / ...... dylib для архитектуры x86_64".
  • Каждый двоичный файл в Framework будет относительным путем "@rpath", и только внешний dylib с полным путем может повторно экспортироваться.
...