В чем разница между "- fembed-bitcode " и режимом генерации битового кода?

Я обновляю статическую библиотеку для поддержки bitcode, и из моих исследований я нашел два способа достичь этого:

  • добавлять fembed-bitcode флаг для другой опции флагов C в моих настройках сборки проекта (ссылке)
  • добавление пользовательской настройки с помощью клавиши BITCODE_GENERATION_MODE значение bitcode (ссылке)

есть ли разница между этими двумя вариантами?

единственная разница Я отметил, что с помощью fembed-bitcode, результирующая статическая библиотека для iphonesimulator будет построена с включенным полным битовым кодом (в моем случае двоичный размер изменяется от 5 Мб до 13 мб, и я могу проверить поддержку битового кода с помощью otool), что, похоже, не имеет никакого значения в его использовании.

1 ответов


когда вы строите библиотеку нормально, с ENABLE_BITCODE=YES, Xcode добавляет флаг сборки -fembed-bitcode-marker для любого вызова clang, помещая" пустой " битовый код в окончательный файл o.

Итак, если вы посмотрите на действие компиляции на этапе сборки, оно будет выглядеть примерно так:

CompileC {build_path} / StaticBitcode / StaticLogger.o StaticBitcode / StaticLogger.M нормальный armv7 objective-C com.яблоко.компиляторы.инфраструктура LLVM.лязг.1_0.компилятор cd {path} / StaticBitcode экспорт LANG=en_US.US-ASCII путь экспорта= " / Applications / Xcode.app / содержание / разработчик / платформы / iPhoneOS.платформа / разработчик / usr / bin: / приложения / Xcode.app / содержание / разработчик / usr / bin: / usr / local / bin: / usr / bin: / bin: / usr / sbin: / sbin" /Применения/Xcode.app / содержание / разработчик / Toolchains / XcodeDefault.xctoolchain/usr/Бен/лязг -х объективный-с-арки ARMv7 с -fmessage-длина=0 -fdiagnostics-шоу-обратите внимание-включать-стек -fmacro-след-лимит=0 -с std=gnu99 -fobjc-дуги -fmodules -gmodules -fmodules-кэш - [...] - fembed-bitcode-маркер [...]

это верно для действия сборки (независимо от цели).

когда вы Build & Archive на -fembed флаг заменить на -fembed-bitcode, который действительно создает двоичный код с поддержкой Bitcode:

CompileC {build_path} / StaticBitcode / StaticLogger.o StaticBitcode / StaticLogger.M нормальный armv7 objective-C com.яблоко.компиляторы.инфраструктура LLVM.лязг.1_0.компилятор компакт {path} / StaticBitcode экспорт LANG=en_US.US-ASCII путь экспорта= " / Applications / Xcode.app / содержание / разработчик / платформы / iPhoneOS.платформа / разработчик / usr / bin: / приложения / Xcode.app / содержание / разработчик / usr / bin: / usr / local / bin: / usr / bin: / bin: / usr / sbin: / sbin" /Применения/Xcode.app / содержание / разработчик / Toolchains / XcodeDefault.xctoolchain / usr / bin / clang-X objective-C-arch armv7-fmessage-length=0-fdiagnostics-показать-Примечание-включить-стек-fmacro-backtrace-limit=0-std=gnu99 -fobjc-arc -fmodules-gmodules - fmodules-кэш - [...] - fembed-bitcode [...]


флаг fembed-bitcode

учитывая это, если вы добавите -fembed-bitcode флаг другим флагам C, вы будете отправлять два флага компилятору во время компиляции. Это может заставить замолчать некоторые предупреждения, которые вы можете получить при использовании библиотеки, связанной с другим проектом. Но вам нужно проверить, получаете ли вы ожидаемое поведение. :)

(когда я тестировал с помощью -fembed-bitcode на других флагах C Xcode дал предупреждение clang: warning: argument unused during compilation: '-fembed-bitcode-marker')


BITCODE_GENERATION_MODE

С другой стороны,

если вы устанавливаете BITCODE_GENERATION_MODE=bitcode на User-defined Setting, даже на этапе сборки файлы будут скомпилированы с использованием флага -fembed-bitcode.

и, если вы задались BITCODE_GENERATION_MODE=marker, файлы будут скомпилированы с использованием флага -fembed-bitcode-marker независимые действия фаза.

Итак, если вы хотите включить биткод для каждого действия (сборки и архивирования), лучший способ сделать это-использовать BITCODE_GENERATION_MODE настройка.


ресурсы