Ответ 1

Мне не удалось успешно его создать, но я преодолел некоторые препятствия, которые могут быть полезны.

Препятствие 1: ARM Thumb2

Сводка: Несмотря на то, что рекламируется как полностью поддерживающая thumb, появляется Apple при условии, что clang, а также LLVM 3.2 невозможно перевести некоторые допустимые инструкции thumb, которые отображаются в коде libav ARM-ассемблера.

Подробности: libav (вилка ffmpeg) имеет некоторую функциональность, реализованную в ассемблере. При создании для iOS используются файлы из MobileVLC/ImportedSources/vlc/contrib/iPhoneOS/ffmpeg/libavcodec/arm. Первая ошибка компиляции, с которой, вероятно, столкнется, похожа на

libavcodec/arm/aacpsdsp_neon.S:132:21: error: invalid operand for instruction
        add r4, r0, #38*64*4

В соответствии с ссылкой ARM Thumb2, приведенная выше инструкция является действительной инструкцией ADD{S} Rd, Rn, <Operand2>, где <Operand2> в thumb режиме "32-битная константа, сформированная левым сдвигом 8-битного значения на любое количество бит". Поскольку #38*64*4 равно 38 сдвинутым влево 8 раз, clang должен принять его. Похоже, что clang не признает это возможным, поэтому пытается интерпретировать инструкцию как ADD Rd, Rn, #<imm12>, для которой ближайший аргумент должен быть меньше 4096.

Если кто-то с большей уверенностью по этому вопросу может относиться - это ошибка в clang?

Временное решение: Как указано в http://forum.videolan.org/viewtopic.php?f=12&t=103271, thumb следует отключить при настройке ffmpeg (что фактически является libav).

Препятствие 2: libtool не может вывести тег

Сводка: MobileVLC libtool сконфигурирована для вывода компиляций С++, ожидающих обращения clang++. Когда система сборки вызывает gas-preprocessor.pl xcrun clang вместо этого, libtool выдает ошибку.

Подробности: MobileVLC настраивает копию libtool (которая всего лишь bash script) в MobileVLC/ImportedSources/vlc/build-ios-OS. В строке 1681 функция func_infer_tag отвечает за вывод тега. Для каждого тега, который отображается в переменной $available_tags, определенной в строке 38, сам поиск libtool выполняется для раздела конфигурации тегов. Например, конфигурация тегов CXX (= С++) начинается в строке 9258. Как видно из строки 9271, команда компилятора, ожидаемая от компиляции С++, xcrun clang++.

Система сборки вызывает что-то вроде libtool --mode=compile gas-preprocessor.pl xcrun clang …, и поскольку xcrun clang++ не префикс команды, режим С++ не может быть выведен. (gas-preprocessor.pl переводит GNU Assembler во что-то, с чем может работать ассемблер Apple)

Временное решение: как отмечено в http://forum.videolan.org/viewtopic.php?f=12&t=103331, MobileVLC/ImportedSources/vlc/modules/video_filter/Modules.am можно изменить, чтобы заставить libtool вывести компиляцию C. Если это не сработает для вас, как и не для меня, вы можете позвонить libtool себе.

cd в MobileVLC/ImportedSources/vlc/build-ios-OS/modules/video_filter; ввод make должен привести к появлению ошибки. Ввод make V=1 также покажет выполняемую команду. Он начнется с source='deinterlace/merge_arm.S' o…. Теперь вы можете скопировать его и вызвать его вручную, добавив --tag=CC после ../../libtool.

Препятствие 3: CopyStringsFile

Сводка: Построение MobileVLC завершается с ошибкой,

The following build commands failed:
    CopyStringsFile build/Release-iphoneos/VLC.app/pl.lproj/Localizable.strings Resources/pl.lproj/Localizable.strings

Подробности: файл-нарушитель, MobileVLC/Resources/pl.lproj/Localizable.strings - это файл UTF-16-LE, отсутствующий в байтах (BOM), который по какой-то причине путает Xcode.

Обходной путь: cd в MobileVLC/Resources/pl.lproj/ и выполните

mv -n Localizable.strings Localizable.strings.backup && python -c "import sys; sys.stdout.write(chr(0xFF)+chr(0xFE))" > Localizable.strings && cat Localizable.strings.backup >> Localizable.strings

Это добавит спецификацию в начало файла.

Препятствие 4: non_lazy_ptr + ​​AmplifyFloat

Сводка: Эта ошибка должна выглядеть следующим образом: "Внутренняя структура данных компоновщика ld имеет указатель на нелатный, который содержит адрес символа ld, который не может найти". Пропущенные символы не могут быть найдены, потому что они не имеют префикса с подчеркиванием.

Подробности: Очевидно, стыдно, что ld не побалует нас знаниями о том, что именно он не может найти, но мы здесь не для того, чтобы говорить.

Рассмотрим следующий простой файл bla.c,

int bla();
int foo() { return bla(); }

Компиляция этого файла (clang -c bla.c), а затем перечисление его символов (nm bla.o) показывает, что компоновщик ожидает, что какой-либо другой модуль компиляции предоставит символ _bla (обратите внимание на подчеркивание). Подчеркнуто, что символ подчеркивания bla должен быть вызван в соглашении о вызове C. Проблема возникает, когда bla определяется в файле ассемблера; ассемблер не добавляет символ подчеркивания, в результате появляется символ bla, что приводит к сбою связи.

Интересная деталь заключается в том, что это поведение отличается от Linux, где подчеркивание не добавляется к именам символов, что, вероятно, помогло проблеме избежать внимания разработчиков VLC. Тем не менее, поведение underscoring появляется в MinGW, насколько я знаю, поэтому решение может быть похоже.

Обходной путь: простейшим решением, даже если ad-hoc, является использование списка псевдонимов символов. Создайте файл symbol-alias.txt со следующим содержимым,

merge16_arm_neon _merge16_arm_neon
merge8_arm_neon _merge8_arm_neon
amplify_float_arm_neon _amplify_float_arm_neon

Этот файл достаточно в зависимости от флагов и конфигураций; этого было достаточно для меня. Введите open MobileVLC.xcodeproj в каталог MobileVLC/. Это должно запуститься Xcode. В настройках проекта выберите цель MobileVLC, а затем Build Settings. В Other Linker Flags добавьте

-Wl,-alias_list
-Wl,<absoluate-path-to-symbol_aliases.txt>

Сохранить и построить. Поздравления. Теперь вы достигли Препятствия, я не знаю, как победить:)

Препятствие 5: Адрес не в любой секции

Сводка: Сбой компоновщика с загадочной ошибкой

ld: in section __TEXT,__text reloc 13: sectionForAddress(0xE142) address not in any section for architecture armv7

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

Ответ 2

Увидим, что вам требуются целевые зависимости libMobileVLCKit