Fix undefined symbol in MacOS dylib #670
Conversation
… to absl::cord as proposed by moubctez on issue abseil#624
|
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed (or fixed any issues), please reply here with What to do if you already signed the CLAIndividual signers
Corporate signers
ℹ️ Googlers: Go here for more info. |
|
|
CLAs look good, thanks! ℹ️ Googlers: Go here for more info. |
KokutoSan
changed the title
|
what is the path of this file " absl/stringsCMakeLists.txt ? i am not finding on my mac. |
Hello Shelps, |
|
Hi, thanks for responding. Maybe I need to do something more, but I don't know. My log Ld /Users/shelps/Library/Developer/Xcode/DerivedData/Runner-aysnqajzcxdixjbdgiakfssyykxo/Build/Intermediates.noindex/ArchiveIntermediates/Runner/IntermediateBuildFilesPath/Pods.build/Release-iphoneos/FirebaseFirestore.build/Objects-normal/armv7/Binary/FirebaseFirestore normal armv7 (in target 'FirebaseFirestore' from project 'Pods') ld: warning: ignoring file /Users/shelps/Library/Developer/Xcode/DerivedData/Runner-aysnqajzcxdixjbdgiakfssyykxo/Build/Intermediates.noindex/ArchiveIntermediates/Runner/BuildProductsPath/Release-iphoneos/abseil/absl.framework/absl, building for iOS-armv7 but attempting to link with file built for iOS-arm64 |
Hi Shelps, If I understand correctly, you have installed the latest macOS Big Sur update and you tried to rebuild your iOS project using Xcode, is it right? May it be possible for you to provide me with a small iOS project that has the same issue so I can try it on my side? |
|
Hello team. I'm also having this issue when compiling Protobuf. Here's the log: Undefined symbols for architecture arm64:
"void absl::lts_20240116::log_internal::LogMessage::CopyToEncodedBuffer<(absl::lts_20240116::log_internal::LogMessage::StringType)0>(std::__1::basic_string_view<char, std::__1::char_traits<char>>)", referenced from:
absl::lts_20240116::log_internal::LogMessage& absl::lts_20240116::log_internal::LogMessage::operator<<<19>(char const (&) [19]) in libproto.a[2](readapi.pb.cc.o)
"absl::lts_20240116::log_internal::LogMessage& absl::lts_20240116::log_internal::LogMessage::operator<<<unsigned long, 0>(unsigned long const&)", referenced from:
absl::lts_20240116::log_internal::LogMessage::operator<<(unsigned long) in libproto.a[2](readapi.pb.cc.o)
"absl::lts_20240116::log_internal::LogMessageFatal::LogMessageFatal(char const*, int, std::__1::basic_string_view<char, std::__1::char_traits<char>>)", referenced from:
IMU6DOF::SharedDtor() in libproto.a[2](readapi.pb.cc.o)
IMU6DOF::MergeImpl(google::protobuf::Message&, google::protobuf::Message const&) in libproto.a[2](readapi.pb.cc.o)
google::protobuf::internal::ArenaAlignAs(unsigned long) in libproto.a[2](readapi.pb.cc.o)
google::protobuf::internal::ArenaAlignAs(unsigned long) in libproto.a[2](readapi.pb.cc.o)
"absl::lts_20240116::log_internal::LogMessageFatal::~LogMessageFatal()", referenced from:
IMU6DOF::SharedDtor() in libproto.a[2](readapi.pb.cc.o)
IMU6DOF::SharedDtor() in libproto.a[2](readapi.pb.cc.o)
IMU6DOF::MergeImpl(google::protobuf::Message&, google::protobuf::Message const&) in libproto.a[2](readapi.pb.cc.o)
IMU6DOF::MergeImpl(google::protobuf::Message&, google::protobuf::Message const&) in libproto.a[2](readapi.pb.cc.o)
google::protobuf::internal::ArenaAlignAs(unsigned long) in libproto.a[2](readapi.pb.cc.o)
google::protobuf::internal::ArenaAlignAs(unsigned long) in libproto.a[2](readapi.pb.cc.o)
google::protobuf::internal::ArenaAlignAs(unsigned long) in libproto.a[2](readapi.pb.cc.o)
google::protobuf::internal::ArenaAlignAs(unsigned long) in libproto.a[2](readapi.pb.cc.o)
...
"std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>* absl::lts_20240116::log_internal::MakeCheckOpString<void const*, void const*>(void const*, void const*, char const*)", referenced from:
std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>* absl::lts_20240116::log_internal::Check_NEImpl<MU6DOF const*,IMU6DOF*>(IMU6DOF const* const&, IMU6DOF* const&, char const*) in libproto.a[2](readapi.pb.cc.o)
"absl::lts_20240116::log_internal::CheckOpMessageBuilder::ForVar2()", referenced from:
std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>* absl::lts_20240116::log_internal::MakeCheckOpString<unsigned long long, long long>(unsigned long long, long long, char const*) in libproto.a[2](readapi.pb.cc.o)
"absl::lts_20240116::log_internal::CheckOpMessageBuilder::NewString()", referenced from:
std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>* absl::lts_20240116::log_internal::MakeCheckOpString<unsigned long long, long long>(unsigned long long, long long, char const*) in libproto.a[2](readapi.pb.cc.o)
"absl::lts_20240116::log_internal::CheckOpMessageBuilder::CheckOpMessageBuilder(char const*)", referenced from:
std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>* absl::lts_20240116::log_internal::MakeCheckOpString<unsigned long long, long long>(unsigned long long, long long, char const*) in libproto.a[2](readapi.pb.cc.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [reader] Error 1
make[1]: *** [CMakeFiles/reader.dir/all] Error 2
make: *** [all] Error 2 |
I've added absl::string dependency to absl::cord as proposed by moubctez on issue #624
The problem is located on LTS 20200225 release of abseil-cpp.
When you want to compile the library as shared object (dylib on MacOS), you get this error:
It is located in libabsl_cord.dylib dependencies.
I've patched the absl/strings/CMakeLists.txt file as described by @moubctez and my compilation of abseil-cpp works as expected:
I don't know if this correction can be also 'cherry-picked' to the master branch but on the "lts_2020_02_25" branch, it is needed in order to build the library as dylib on MacOS.
I've tested this correction on both MacOS Mojave and MacOS Catalina.