C++: Undefine reference to functions defined in absl::lts_20230125
#12292
Comments
anandolee
removed
the
untriaged
|
This signals that our Abseil dependency isn't being properly linked in. If you have a system installation at the wrong version that could explain it |
I'm sorry but I have only one protobuf, it is installed at the compiler's prefix. So find_package must have found the correct one, but some absl libs are not linked to my executable. I have tried manually adding many absl libs links to executable, but I still failed. Do you know which library in absl should be linked? |
|
I can confirm this issue. getting abseil log related linking issues with both MinGW and Visual Studio 2022. Here is the linking issue with Visual Studio 2022: Here is how I build protobuf with abseil for Visual Studio: For MinGW I build Protobuf with |
Thanks! I'm glad to see that I'm not the only one who meets this weird issue. Your code implies that developer should link |
|
Our Abseil dependency is public, so I'm not sure why it isn't getting pulled in transitively. Both of the cmake targets you mentioned are new to Abseil's latest LTS release (20230125.2). This tells me that you have an older version of Abseil installed on your system that's missing these libraries. Setting |
|
There isn't any older abseil version installed. I'm getting similar log_internal related linking errors in 4 places including cross-compiling on Linux, a clean Windows 10 MSVC physical machine, github actions both MSVC and MinGW cross-compilation, cross-compiling on my own linux machine . Setting protobuf_ABSL_PROVIDER to module doesn't help. |
|
hmm lemme see if I can try to reproduce this then. We test against MSVC in our CI, so I'm not sure what the issue could be here |
|
Just to clarify, the linking errors does not occur when compiling protobuf itself, but occurs when compiling my own program with protobuf, so the linker flags for the abseil libraries aren't passed on for some reason, I spent a few hours looking into it, but could not figure it out. |
|
Can you provide the commands you use to build and install protobuf too? Also, do the missing targets end up in the installation |
Same issue here.I am build protobuffer for android. my commands
Errorld: error: undefined symbol: absl::lts_20230125::Mutex::~Mutex()
ld: error: undefined symbol: absl::lts_20230125::base_internal::SpinLockWait(std::__ndk1::atomic, int, absl::lts_20230125::base_internal::SpinLockWaitTransition const, absl::lts_20230125::base_internal::SchedulingMode) |
|
I believe the issue is that something like https://cmake.org/cmake/help/latest/module/FindProtobuf.html This package has not been updated to know about the find_package(protobuf REQUIRED CONFIG) |
|
Hah thank you Carlos! That perfectly explains why our examples directory is building ok but this one isn't :) |
|
Not sure if related, but we are having same problem (tons of |
|
Sounds related, the fix here was to specify |
See also: protocolbuffers/protobuf#12292. Signed-off-by: Tao He <[email protected]>
See also: protocolbuffers/protobuf#12292 Signed-off-by: Tao He <[email protected]>
Google introduced abseil as a new dependency of Protobuf, but CMake's FindProtobuf hasn't been updated yet to link with abseil. Thus, CMake is now advised to use the config provided by Protobuf instead of its own. In case no config can be found, we fall back to the old behavior. The Protobuf version constraint is removed since it only applies with `P4C_USE_PREINSTALLED_PROTOBUF=ON` anyway, in which case we'll want to use whatever preinstalled version is available. Furthermore, the variables `PROTOBUF_LIBRARY` and `PROTOBUF_PROTOC_EXECUTABLE` are set correctly so executing `protoc` and linking with Protobuf doesn't fail. Fix #4055 See also protocolbuffers/protobuf#12292
|
hello, I'm following this https://github.com/protocolbuffers/protobuf/blob/main/docs/cmake_protobuf_generate.md
am I missing something? If so, please update file at the link |
|
I have same issue |
|
Compiling with |
|
Seems that this issue was caused by the fact that the relevant Protobuf_* variables are empty, even find_package return Protobuf_FOUND=true. related issue Have struggled days to solve this issue and found 2 solutions. #1 set protobuf_MODULE_COMPATIBLE variable mentioned in the above link. set(protobuf_MODULE_COMPATIBLE true) #2 Issuing double calls to find_package() find_package(Protobuf CONFIG) In my case, both work on linux and windows. |
|
Sorry for stupid questions, but I am pretty new to protobuf and abseil. I am getting the same linker errors for my own project. I am using MSVC 17 2022 Windows 11 and I do not have cmakelists.txt file in my project. So, I am stuck here from last few weeks. Would be greatful if someone can help me in getting it fixed. I did not post alloff the errors but they are related to absl. |
This still doesn't do it for me. My cmake file is like this: Still get all the linker issues like:
|
|
I had the same errors with integration gRPC (1.59.3) build on Windows, which depends on abseil and protobuf (4.24.3) as well. finally solved with abseil specific flags: |
|
I got the same error during building my code using protobuf 3.21. The approach @pascaldekloe left in his comment above worked for me, where I use c++20. In CMakeLists.txt, No cmake variable |
This patch makes the Protobuf package mandatory in addition to forcing a
config mode search. The (default) module mode search looks for the
CMake-provided FindProtobuf.cmake file, but this file does not list
Abseil as a dependency, causing linker issues like the one below:
```
ld: Undefined symbols:
absl::lts_20230802::log_internal::LogMessageFatal::LogMessageFatal(char const*, int, std::__1::basic_string_view<char, std::__1::char_traits<char>>), referenced from:
google::protobuf::RepeatedPtrField<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>::TypeHandler::Type const& google::protobuf::internal::RepeatedPtrFieldBase::Get<google::protobuf::RepeatedPtrField<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>::TypeHandler>(int) const (.cold.1) in OnnxImporter.cpp.o
```
By forcing a config mode search, CMake looks for the file that is
installed as part of the protobuf package and which does contain the
Abseil dependency. This workaround is also mentioned in a GitHub issue
for Protobuf:
protocolbuffers/protobuf#12292 (comment).
This patch makes the Protobuf package mandatory in addition to forcing a
config mode search. The (default) module mode search looks for the
CMake-provided FindProtobuf.cmake file, but this file does not list
Abseil as a dependency, causing linker issues like the one below:
```
ld: Undefined symbols:
absl::lts_20230802::log_internal::LogMessageFatal::LogMessageFatal(char const*, int, std::__1::basic_string_view<char, std::__1::char_traits<char>>), referenced from:
google::protobuf::RepeatedPtrField<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>::TypeHandler::Type const& google::protobuf::internal::RepeatedPtrFieldBase::Get<google::protobuf::RepeatedPtrField<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>::TypeHandler>(int) const (.cold.1) in OnnxImporter.cpp.o
```
By forcing a config mode search, CMake looks for the file that is
installed as part of the protobuf package and which does contain the
Abseil dependency. This workaround is also mentioned in a GitHub issue
for Protobuf:
protocolbuffers/protobuf#12292 (comment).
|
I'm compiling the code of a program I downloaded from GitHub that employs emscripten and protobuf v25.3 for Windows 11 using this command line:
I've worked on this for several hours. It turned out that the order of the '.a' files had a great impact on the error messages I received. Anyway, now most of the error messages I initially had are gone and the remaining ones are in the kind of:
And that puzzles me because I've included all '.a' files from abseil and linked libprotobuf.a after them. So what's wrong? I suspect it's related to string_view but I might err. After some consideration I think that maybe the wrong version of abseil is used because if I use a different version of libprotobuf.a, the error message also includes a different version date for abseil. |
|
I also encountered this problem when using grpc, and I found a solution that worked for me on stackoverflow Original text： Following its approach, I uninstalled all of my protobuf versions and then recompiled grpc once, under linux |
Hello! I think it's really useful, but I have the problem there: Maybe someone has already encountered this and knows the solution |
|
Still getting a lot of absl reference errors after |
Have you solved this problem yet？ |
|
I managed to install protobuf 28.1 on windows with VS2022:
Then for linkage: |
and others
What version of protobuf and what language are you using?
Version: v22.2
Language: C++
What operating system (Linux, Windows, ...) and version?
Windows 11
What runtime / compiler are you using (e.g., python version or gcc version)
gcc12.2.0 (mingw)
What did you do?
CMakeLists.txt,test.protoandmain.cpp. They are located in same dir.cmake --build .What did you expect to see
My code is compiled with no error.
What did you see instead?
22 errors was reported:
It seems that many functions defined in
absl::lts_20230125can not be found by the linker.Anything else we should know about your project / environment
Version of my cmake: 3.26.0-rc6
ABSL is not installed before I configure protobuf, so it must be installed together with protobuf.
The command used to clone protobuf repo:
The command used to configure protobuf:
The text was updated successfully, but these errors were encountered: