Crashlytics error "Undefined symbols for architecture x86_64" during Pod installation

Question

I am using Google Analytics and after pod installation when I run, these error are shown. I am not getting why; project has Crashlytics framework as well, but these errors are shown only after adding 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)

Could you show your pod file? And the version of your Deployment Target? — J. Lopes, May 12 '16 at 11:34
Almost certainly an issue with the two C++ runtime libraries which are available (`libstdc++` and `libc++`). All code needs to be compiled against the same runtime library, which is most certainly `libc++`. It's also possible you are not linking against *any* C++ runtime library. — trojanfoe, May 12 '16 at 12:19

Santosh · Answer 1 · 2016-10-09T15:02:24.147

For me I had similar issue, while integrating this for cordova based app.

The particular error you are seeing is because libc++ is not being linked. Crashlytics 3.0 requires libc++ (not libstdc++), libz, SystemConfiguration.framework, and Security.framework. Linking should be taken care of automatically by the module definition within the SDK. If you do not use modules, our guided installation is supposed to insert the needed libraries for linking. That obviously did not work in this case.

Solution #1: start using modules. They improve build times, make interoperability with swift possible, and are generally useful.

Solution #2: manually link libc++, libz, SystemConfiguration.framework, and Security.framework. Solution #2 - Worked for me This answer is Ref link by mattie

solution 2 worked though i didn't require to add libz. – shahil Jan 23 '17 at 17:18 — shahil, Jan 23 '17 at 17:18

score 1 · Accepted Answer · answered Aug 17 '17 at 01:27

In Xcode Santosh's answer not worked for me but I just change the .m file to .mm file works .

Here is the differences between .mm & .m

The major disadvantage to using .mm over .m for "normal" Objective-C is that compile times are significantly higher for Objective-C++. This is because the C++ compiler takes longer than the C compiler. With Xcode 3.2 and higher, Objective-C code can use the Clang frontend tool chain to significantly speed up Objective-C/C compiling times. Since Clang does not yet support Objective-C++/C++, this further widens the gap in compiling times between the two.

A better strategy is to use .m by default. If you need to use Objective-C++ later in development, there is no harm in renaming the file to use a .mm extension. If you so from within XCode, the project will be automatically updated to use the newly named file.

Of course all of the standard caveats apply once you try to compare Objective-C++ vs. Objective-C performance at run time. Since Objective-C++ is a C++ superset while Objective-C is a C superset, you are dealing with two different languages each with performance tradeoffs at runtime. Given that you're using Objective-X at all, you are likely writing a user-level application (not a systems level app) and the difference in performance between C and C++ wil likely be completely determined by your abilities to code efficient algorithms in each language. If you're a C++ developer, you'll likely code better than in C and visa versa. So, as always, use the appropriate tool for the job.

For reference, you may also be interested in this answer: C vs C++ (Objective-C vs Objective-C++) for iPhone

UPDATE Feb 17, 2012 As of Xcode 4.0 (with LLVM 3.0), Clang has supported Objective-C++. Even C++11 support is quite strong now.

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

Crashlytics error "Undefined symbols for architecture x86_64" during Pod installation

2 Answers2