Ошибка Crashlytics «Неопределенные символы для архитектуры x86_64» во время установки Pod

Question

Я использую Google Analytics и после установки pod, когда я запускаю, отображаются эти ошибки. Я не понимаю, почему; проект также имеет структуру Crashlytics, но эти ошибки отображаются только после добавления Google Analytics.

Undefined symbols for architecture x86_64: 
    "std::get_terminate()", referenced from: 
    _CLSExceptionCheckHandlers in Crashlytics(CLSException.o) 
"std::set_terminate(void (*)())", referenced from: 
    _CLSExceptionInitialize in Crashlytics(CLSException.o) 
    CLSTerminateHandler() in Crashlytics(CLSException.o) 
"std::terminate()", referenced from: 
    ___clang_call_terminate in Crashlytics(CLSException.o) 
"typeinfo for char const*", referenced from: 
    _CLSExceptionRaiseTestCppException in Crashlytics(CLSException.o) 
    GCC_except_table1 in Crashlytics(CLSException.o) 
"typeinfo for std::exception", referenced from: 
    GCC_except_table1 in Crashlytics(CLSException.o) 
    typeinfo for std::exception const* in Crashlytics(CLSException.o) 
"vtable for __cxxabiv1::__class_type_info", referenced from: 
    typeinfo for std::__1::__basic_string_common<true> in Crashlytics(CLSException.o) 
NOTE: a missing vtable usually means the first non-inline virtual member function has no definition. 
"vtable for __cxxabiv1::__pointer_type_info", referenced from: 
    typeinfo for std::exception const* in Crashlytics(CLSException.o) 
NOTE: a missing vtable usually means the first non-inline virtual member function has no definition. 
"vtable for __cxxabiv1::__vmi_class_type_info", referenced from: 
    typeinfo for std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > in Crashlytics(CLSException.o) 
NOTE: a missing vtable usually means the first non-inline virtual member function has no definition. 
"___cxa_allocate_exception", referenced from: 
    _CLSExceptionRaiseTestCppException in Crashlytics(CLSException.o) 
"___cxa_begin_catch", referenced from: 
    CLSTerminateHandler() in Crashlytics(CLSException.o) 
    ___clang_call_terminate in Crashlytics(CLSException.o) 
"___cxa_current_exception_type", referenced from: 
    CLSTerminateHandler() in Crashlytics(CLSException.o) 
"___cxa_demangle", referenced from: 
    +[CLSDemangleOperation demangleCppSymbol:] in Crashlytics(CLSDemangleOperation.o) 
"___cxa_end_catch", referenced from: 
    CLSTerminateHandler() in Crashlytics(CLSException.o) 
"___cxa_rethrow", referenced from: 
    CLSTerminateHandler() in Crashlytics(CLSException.o) 
"___cxa_throw", referenced from: 
    _CLSExceptionRaiseTestCppException in Crashlytics(CLSException.o) 
"___gxx_personality_v0", referenced from: 
    +[CLSDemangleOperation demangleBlockInvokeCppSymbol:] in Crashlytics(CLSDemangleOperation.o) 
    +[CLSDemangleOperation demangleSwiftSymbol:] in Crashlytics(CLSDemangleOperation.o) 
    -[CLSDemangleOperation main] in Crashlytics(CLSDemangleOperation.o) 
    ___28-[CLSDemangleOperation main]_block_invoke in Crashlytics(CLSDemangleOperation.o) 
    Dwarf Exception Unwind Info (__eh_frame) in Crashlytics(CLSDemangleOperation.o) 
ld: symbol(s) not found for architecture x86_64 
clang: error: linker command failed with exit code 1 (use -v to see invocation) 

Answer 1

Для меня у меня была аналогичная проблема, интегрируя это для приложения на основе кордовы.

Особая ошибка, которую вы видите, связана с тем, что libC++ не связан. Для Crashlytics 3.0 требуется libC++ (не libstdC++), libz, SystemConfiguration.framework и Security.framework. Связывание должно выполняться автоматически с помощью определения модуля в SDK. Если вы не используете модули, наша управляемая установка должна вставить необходимые библиотеки для связывания. В этом случае это явно не сработало.

Решение №1: начать использовать модули. Они улучшают время сборки, обеспечивают оперативную совместимость с быстрым возможным и, как правило, полезны.

Решение №2: ручная ссылка libC++, libz, SystemConfiguration.framework и Security.framework. Решение # 2 - работал для меня Этот ответ Ref link по Мэтти

Answer 2

В ответ Xcode Сантош не работал для меня, но я просто изменить файл .m в .mm файл работы.

Здесь различия между .mm & .m

Основным недостатком в использовании .mm над .m для «нормальной» Objective-C является то, что время компиляции значительно выше для Objective-C++. Это связано с тем, что компилятор C++ занимает больше времени, чем компилятор C. С Xcode 3.2 и выше код Objective-C может использовать цепочку инструментов интерфейса Front Clang, чтобы значительно ускорить время компиляции Objective-C/C. Поскольку Clang еще не поддерживает Objective-C++/C++, это еще больше расширяет пробел в времени компиляции между ними.

Лучшей стратегией является использование .m по умолчанию. Если вам нужно использовать Objective-C++ позже в разработке, нет никакого вреда в переименовании файла для использования расширения .mm. Если вы так из XCode, проект будет автоматически обновлен для использования вновь названного файла.

Конечно, все стандартные оговорки применяются, если вы попытаетесь сравнить производительность Objective-C++ и Objective-C во время выполнения. Поскольку Objective-C++ является супермножеством C++, тогда как Objective-C является супермножеством C, вы имеете дело с двумя разными языками, каждый из которых имеет компромисс производительности во время выполнения. Учитывая, что вы используете Objective-X вообще, вы, скорее всего, пишете приложение на уровне пользователя (а не на уровне системного приложения), а разница в производительности между C и C++ wil, вероятно, будет полностью определяться вашими способностями кодировать эффективные алгоритмы в каждый язык. Если вы разработчик C++, скорее всего, код будет лучше, чем на C и наоборот. Поэтому, как всегда, используйте соответствующий инструмент для работы.

Для справки, вы также можете быть заинтересованы в этом ответе: C против C++ (Objective-C против Objective-C++) для iPhone

UPDATE 17 февраля 2012 По состоянию на Xcode 4.0 (с LLVM 3.0), Clang поддерживает Objective-C++. Даже поддержка C++ 11 довольно сильная.

(Objective-C, .m/.mm performance difference?)