protocolbuffers / protobuf

Protocol Buffers - Google's data interchange format
http://protobuf.dev
Other
65.75k stars 15.51k forks source link

C++20: unresolved external symbol with absl::lts_20230125.3 #12693

Closed warsark closed 1 year ago

warsark commented 1 year ago

combiler:MSVC2022 17.5.4 absil:20230125.3 protobuf: 22.4 build static library with static runtime and c++14

my program build C++14 is ok! but C++20 build fail: error LNK2019: unresolved external symbol "private: void thiscall absl::lts_20230125::log_internal::LogMessage::CopyToEncodedBuffer error LNK2001: unresolved external symbol "private: void thiscall absl::lts_20230125::log_internal::LogMessage::CopyToEncodedBuffer error LNK2001: unresolved external symbol "private: void thiscall absl::lts_20230125::log_internal::LogMessage::CopyToEncodedBuffer error LNK2001: unresolved external symbol "public: thiscall absl::lts_20230125::log_internal::LogMessageFatal::LogMessageFatal error LNK2001: unresolved external symbol "public: thiscall absl::lts_20230125::log_internal::LogMessageFatal::LogMessageFatal error LNK2001: unresolved external symbol "public: thiscall absl::lts_20230125::log_internal::LogMessageFatal::LogMessageFatal

bc-lee commented 1 year ago

I found the same issue and found the root cause of the problem. The problem is that my code is compiled with C++17, but abseil itself is compiled with C++14, so there is a mismatch of ABSL_OPTION_USE_STD_STRING_VIEW value. I fixed the issue by compiling abseil with C++17.

Note that I was using ABSL_PROPAGATE_CXX_STD but I missed setting CMAKE_CXX_STANDARD to 17. target_compile_features(${TARGET} PUBLIC cxx_std_17) is flexible to use, but it seems the old school set(CMAKE_CXX_STANDARD 17) makes entire codebase to use C++17 much easier.

warsark commented 1 year ago

I found the same issue and found the root cause of the problem. The problem is that my code is compiled with C++17, but abseil itself is compiled with C++14, so there is a mismatch of ABSL_OPTION_USE_STD_STRING_VIEW value. I fixed the issue by compiling abseil with C++17.

Note that I was using ABSL_PROPAGATE_CXX_STD but I missed setting CMAKE_CXX_STANDARD to 17. target_compile_features(${TARGET} PUBLIC cxx_std_17) is flexible to use, but it seems the old school set(CMAKE_CXX_STANDARD 17) makes entire codebase to use C++17 much easier.

thanks a lot!!! change all value 2 to 1 in file:\third_party\abseil-cpp\absl\base\options.h add set(CMAKE_CXX_STANDARD 17) in protobuf cmakelists.txt and absil cmakelists.txt and utf8_range cmakelists.txt then regenerate and build is ok!

adokhugi commented 7 months ago

I'm also getting the error:

Severity    Code    Description Project File    Line    Suppression State
Error   LNK2001 unresolved external symbol "bool __cdecl utf8_range::IsStructurallyValid(class absl::lts_20240116::string_view)" (?IsStructurallyValid@utf8_range@@YA_NVstring_view@lts_20240116@absl@@@Z)  greeter C:\Projects\soft\grpc\examples\cpp\greeter\libprotobuf.lib(generated_message_tctable_lite.obj)  1   

using Visual Studio 2022. I've already tried modifying the C++ version but when I switched to C++ 17 the effect was only that some additional error messages appeared.

adokhugi commented 7 months ago

I've solved the problem I had. It was not related to abseil but to utf8-range. There were two different versions of this library on my system and I'd chosen the wrong one.