Errore di Crashlytics "Simboli indefiniti per architettura x86_64" durante l'installazione di Pod

Question

Sto utilizzando Google Analytics e dopo l'installazione di pod quando corro, vengono visualizzati questi errori. Non capisco perché; il progetto ha anche un framework Crashlytics, ma questi errori vengono mostrati solo dopo aver aggiunto 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

Per quanto mi riguarda ho avuto problema simile, integrando questo per un'applicazione basata Cordova.

L'errore particolare che si sta verificando è dovuto al fatto che libC++ non è collegato. Crashlytics 3.0 richiede libC++ (non libstdC++), libz, SystemConfiguration.framework e Security.framework. Il collegamento deve essere gestito automaticamente dalla definizione del modulo all'interno dell'SDK. Se non si utilizzano i moduli, la nostra installazione guidata dovrebbe inserire le librerie necessarie per il collegamento. Questo ovviamente non ha funzionato in questo caso.

Soluzione n. 1: iniziare a utilizzare i moduli. Migliorano i tempi di costruzione, rendono l'interoperabilità rapida possibile e sono generalmente utili.

Soluzione n. 2: collegamento manuale di libC++, libz, SystemConfiguration.framework e Security.framework. Soluzione # 2 - Ha lavorato per me Questa risposta è Ref link da Mattie

Answer 2

In risposta di Xcode Santosh non ha funzionato per me, ma mi basta cambiare il file .m a .MM opere di file.

Ecco le differenze tra .mm & .m

Il principale svantaggio di utilizzare .mm sopra .m per "normale" Objective-C è che i tempi di compilazione sono significativamente più alta per Objective-C++. Questo perché il compilatore C++ impiega più tempo del compilatore C. Con Xcode 3.2 e versioni successive, il codice Objective-C può utilizzare la catena di strumenti di frontend di Clang per velocizzare significativamente i tempi di compilazione Objective-C/C. Dato che Clang non supporta ancora Objective-C++/C++, questo allarga ulteriormente il tempo di compilazione tra i due.

Una strategia migliore consiste nell'utilizzare .m per impostazione predefinita. Se è necessario utilizzare Objective-C++ più avanti nello sviluppo, non c'è nulla di male nel rinominare il file per usare un'estensione .mm. Se lo fai da dentro XCode, il progetto verrà automaticamente aggiornato per utilizzare il file appena nominato.

Ovviamente tutti gli avvertimenti standard si applicano quando si tenta di confrontare le prestazioni Objective-C++ rispetto a Objective-C in fase di esecuzione. Poiché Objective-C++ è un superset C++ mentre Objective-C è un superset C, si hanno a che fare con due linguaggi diversi ciascuno con compromessi di prestazioni in fase di esecuzione. Dato che stai usando Objective-X, probabilmente stai scrivendo un'applicazione a livello utente (non un'app a livello di sistema) e la differenza di prestazioni tra C e C++ sarà probabilmente completamente determinata dalle tue capacità di codificare algoritmi efficienti in ogni lingua. Se sei uno sviluppatore C++, probabilmente codifichi meglio rispetto a C e viceversa. Quindi, come sempre, usa lo strumento appropriato per il lavoro.

Per riferimento, si può anche essere interessati a questa risposta: C vs C++ (Objective-C vs Objective-C++) per iPhone

UPDATE Feb 17, 2012 Come di Xcode 4.0 (con LLVM 3.0), Clang ha supportato Objective-C++. Anche il supporto per C++ 11 è abbastanza forte ora.

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