Lỗi Crashlytics "Biểu tượng không xác định cho kiến ​​trúc x86_64" trong khi cài đặt Pod

Question

Tôi đang sử dụng Google Analytics và sau khi cài đặt nhóm khi chạy, lỗi này được hiển thị. Tôi không hiểu tại sao; dự án cũng có khung Crashlytics, nhưng những lỗi này chỉ được hiển thị sau khi thêm 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

Đối với tôi, tôi gặp vấn đề tương tự khi tích hợp ứng dụng này cho ứng dụng dựa trên cordova.

Lỗi cụ thể mà bạn đang thấy là do libC++ không được liên kết. Crashlytics 3.0 yêu cầu libC++ (không phải libstdC++), libz, SystemConfiguration.framework và Security.framework. Việc liên kết phải được tự động xử lý bởi định nghĩa mô-đun trong SDK. Nếu bạn không sử dụng các mô-đun, cài đặt có hướng dẫn của chúng tôi được cho là chèn các thư viện cần thiết để liên kết. Điều đó rõ ràng không hoạt động trong trường hợp này.

Giải pháp # 1: bắt đầu sử dụng mô-đun. Chúng cải thiện thời gian xây dựng, làm cho khả năng tương tác nhanh chóng và có thể hữu ích.

Giải pháp # 2: liên kết thủ công libC++, libz, SystemConfiguration.framework và Security.framework. Giải pháp # 2 - Làm việc đối với tôi Câu trả lời này là Ref link bởi Mattie

Answer 2

Trong câu trả lời Xcode Santosh không phải làm việc cho tôi nhưng tôi chỉ cần thay đổi các tập tin .m để .mm công trình tập tin.

Đây là sự khác biệt giữa .mm & .m

Những bất lợi lớn cho việc sử dụng .mm trên .m cho "bình thường" Objective-C là biên dịch thời gian được tính cao hơn đáng kể cho Objective-C++. Điều này là do trình biên dịch C++ mất nhiều thời gian hơn trình biên dịch C. Với mã Xcode 3.2 trở lên, mã Objective-C có thể sử dụng chuỗi công cụ Clang frontend để tăng tốc đáng kể thời gian biên dịch Objective-C/C. Vì Clang chưa hỗ trợ Objective-C++/C++, điều này càng mở rộng khoảng cách trong thời gian biên dịch giữa hai.

Chiến lược tốt hơn là sử dụng .m theo mặc định. Nếu bạn cần sử dụng Objective-C++ sau này trong phát triển, không có hại trong việc đổi tên tệp để sử dụng phần mở rộng .mm. Nếu bạn như vậy từ bên trong XCode, dự án sẽ được tự động cập nhật để sử dụng tệp mới được đặt tên.

Tất nhiên tất cả các tiêu chuẩn áp dụng trước khi bạn cố gắng so sánh hiệu suất mục tiêu-C++ so với mục tiêu-C trong thời gian chạy. Vì Objective-C++ là một siêu dữ liệu C++ trong khi Objective-C là một superset C, bạn đang làm việc với hai ngôn ngữ khác nhau với mỗi sự cân bằng hiệu năng khi chạy. Do bạn đang sử dụng Objective-X, bạn có thể viết một ứng dụng cấp người dùng (không phải ứng dụng cấp hệ thống) và sự khác biệt về hiệu suất giữa C và C++ wil có thể được xác định hoàn toàn bởi khả năng của bạn để mã hóa các thuật toán hiệu quả trong mỗi ngôn ngữ. Nếu bạn là nhà phát triển C++, bạn sẽ có khả năng mã tốt hơn trong C và ngược lại. Vì vậy, như mọi khi, sử dụng công cụ thích hợp cho công việc.

Để tham khảo, bạn cũng có thể quan tâm đến câu trả lời này: C vs C++ (Objective-C vs Objective-C++) cho iPhone

CẬP NHẬT 17 tháng 2 năm 2012 Tính đến Xcode 4.0 (với LLVM 3.0), Clang đã hỗ trợ Objective-C++. Ngay cả hỗ trợ C++ 11 cũng khá mạnh.

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