Pod 安装期间出现 Crashlytics 错误 "Undefined symbols for architecture x86_64"

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

我正在使用 Google Analytics,当我 运行 安装 Pod 后,会显示这些错误。我不明白为什么;项目也有 Crashlytics 框架,但这些错误仅在添加 Google 分析后显示。

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)

对我来说,在为基于 cordova 的应用程序集成时遇到了类似的问题。

您看到的特定错误是因为没有 linked libc++。 Crashlytics 3.0 需要 libc++(不是 libstdc++)、libz、SystemConfiguration.framework 和 Security.framework。链接应该由 SDK 中的模块定义自动处理。如果您不使用模块,我们的指导安装应该会插入 linking 所需的库。这显然在这种情况下不起作用。

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

解决方案 #2:手动 link libc++、libz、SystemConfiguration.framework 和 Security.framework。 解决方案 #2 - 对我有用 这个答案是 Ref link 作者 mattie

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

.mm 和 .m 的区别

对于 "normal" 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?)