Ошибка Clang / LLVM статической библиотеки iPhone: non_lazy_symbol_pointers - PullRequest
0 голосов
/ 15 марта 2012

После нескольких часов экспериментов мне удалось свести проблему к следующему примеру (C ++):

extern "C" void foo();

struct test
{
    ~test() { }
};

void doTest()
{
    test t; // 1
    foo();  // 2
}

Это компилируется для устройств iOS в XCode 4.2 с использованием прилагаемого компилятора Clang.(Компилятор Apple LLVM 3.0) и iOS 5.0 SDK.Проект настроен как статическая библиотека Cocoa Touch, а для параметра «Включить связывание с общими библиотеками» задано значение «Нет», поскольку я создаю собственное расширение AIR.Функция foo определена в другой внешней библиотеке.(В моем реальном проекте это была бы любая из функций C API, определенных Adobe для использования в собственных расширениях AIR.)

При попытке скомпилировать этот код я получаю сообщение об ошибке:

FATAL:incompatible feature used: section type non_lazy_symbol_pointers (must specify "-dynamic" to be used)
clang: error: assembler command failed with exit code 1 (use -v to see invocation)

Ошибка исчезнет, ​​если я закомментирую одну из строк, помеченных 1 или 2 выше, или если я изменю настройку сборки «Включить связывание с общими библиотеками» на Да.(Однако, если я изменяю настройку сборки, то получаю несколько предупреждений ld warning: unexpected srelocation type 9 при связывании библиотеки с конечным проектом, и происходит сбой приложения при запуске на устройстве.) Ошибка сборки также исчезает, если я удаляю деструкторtest.

Итак: это ошибка в Clang?Я пропускаю некоторые важные и недокументированные настройки сборки?Взаимодействие между предоставляемой извне функцией и структурой с деструктором, по меньшей мере, очень своеобразно.

1 Ответ

3 голосов
/ 17 марта 2012

После долгих поисков я, наконец, наткнулся на превосходную запись в блоге Ричарда Лорда о собственных расширениях AIR . Оказывается, что эффективная разработка требует использования нескольких флагов, которые Adobe пока не удосужилась документировать (если вы не считаете посты разработчиков в блогах документацией - я этого не делаю).

Короче говоря:

  • Установите «Включить связывание с общими библиотеками» на «Да». Если задать для этого параметра значение «Нет», это самый распространенный плохой совет, касающийся разработки собственных расширений AIR.
  • Используйте параметр ADT -platformsdk, чтобы указать на iOS SDK, предоставленный Apple (пример: -platformsdk /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk). Это ослабит предупреждения unexpected srelocation type 9. Документация Adobe гласит, что -platformsdk предназначен только для Android, но это ложь.
  • При упаковке расширения (то есть при создании файла ANE) используйте недокументированную опцию -platformoptions, чтобы указать файл XML, содержащий дополнительные аргументы компоновщика. Формат этого XML-файла также недокументирован, но шаблон можно найти в каталоге AIR SDK в templates/extensions/ios/platform-descriptor-template.xml. Там же есть схема xsd в том же месте. Этот файл позволяет указать любые дополнительные платформы, используемые вашим расширением, поэтому вы не будете ограничены средами по умолчанию, которые поддерживает AIR SDK.
  • Ожидайте появления нового предупреждения компоновщика: ld: warning: ARM function not 4-byte aligned. Это, очевидно, можно смело игнорировать. Как сообщается, Adobe знает об этой проблеме. Я полагаю, что вы можете отключить это предупреждение, передав -w компоновщику в файле platformoptions, но помните, что -w заставляет замолчать все предупреждения, а не только это.

Дополнительную информацию можно найти в этих двух сообщениях в блоге Раджорши Гоша, одного из инженеров Adobe:

Это все еще не объясняет странное взаимодействие между «Включить связывание с общими библиотеками», внешне определенными функциями и деструкторами, но теперь это сводится к любопытству, а не к проблеме блокировки.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...