Pod 安装期间出现 Crashlytics 错误“架构 x86_64 的未定义符号”

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

对我来说，我有类似的问题，同时将其集成到基于 cordova 的应用程序中。

您看到的特定错误是因为未链接 libc++。 Crashlytics 3.0 需要 libc++（不是 libstdc++）、libz、SystemConfiguration.framework 和 Security.framework。链接应该由 SDK 中的模块定义自动处理。如果您不使用模块，我们的指导安装应该会插入所需的库以进行链接。在这种情况下，这显然行不通。

解决方案 #1：开始使用模块。它们缩短了构建时间，使与 swift 的互操作性成为可能，并且通常很有用。

解决方案 #2：手动链接 libc++、libz、SystemConfiguration.framework 和 Security.framework。 解决方案 #2 - 为我工作 这个答案是 Ref link by mattie

Answer 2

在 Xcode Santosh 的回答对我不起作用，但我只是将 .m 文件更改为 .mm 文件可以工作。

这是 .mm 和 .m 之间的区别

在“普通”Objective-C 中使用 .mm 而不是 .m 的主要缺点是 Objective-C++ 的编译时间要长得多。这是因为 C++ 编译器比 C 编译器需要更长的时间。在 Xcode 3.2 及更高版本中，Objective-C 代码可以使用 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++ 之间的性能差异可能完全取决于您编写高效算法的能力每种语言。如果您是 C++ 开发人员，您可能会比 C 编写更好的代码，反之亦然。因此，一如既往地为工作使用适当的工具。

作为参考，您可能也对这个答案感兴趣：C vs C++ (Objective-C vs Objective-C++) for iPhone

2012 年 2 月 17 日更新 从 Xcode 4.0（使用 LLVM 3.0）开始，Clang 已支持 Objective-C++。甚至现在对 C++11 的支持也很强大。

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