abseil-cpp | Abseil Common Libraries (C++) | Runtime Evironment library

TLDR: Follow the Conan docs, especially the cmake_find_package docs and skim the cheatsheet.

Following @Tsyvarev's advice in the comments, I used a different setup and made this work, you can see the final result in conan branch.

The steps are as follows:

1. Use Conan to download and install Abseil, using a project-local conanfile.txt. Now, "install" is a scary word (I did not want to modify global state), but Conan essentially just caches sources and build artifacts, which means that you can have multiple versions of the same libraries in different directories, and different projects can use these different versions, and it should "just work". (At least, that's my basic understanding so far.)

Well Guys, After spending almost 12 hours of research, I have made my day. I have exactly figured out what was wrong with my development setup in (VS2019/Clion) of using static webrtc.lib in executable projects.

The standard is very vague about several aspects of template argument usage, including which template parameter “corresponds” to each argument. [temp.arg]/1 merely says

When the parameter declared by the template is a template parameter pack, it will correspond to zero or more template-arguments.

which can be read as saying that any and all template arguments (past those for any prior template parameters) not just can but do correspond to the template parameter pack.

Note that it is still possible to specify template arguments for the pack explicitly—the point is that it’s useless, since you can’t for the following (i.e., meaningful) template parameters. The use of a type like int& is just to make it less likely that you would succeed in doing so accidentally and think it accomplished something.

I suggest that instead of adding it as a subdirectory, install and use it through find_package. Looks like the find_package support was implemented.

In your CMakeLists.txt:

Thank all.

I haven't seen here "Available Abseil CMake Public Targets" that for random shoud be absl::random_random

CMakeLists.txt should be like:

It looks like C++20 support is underway, e.g. removing result_of and uses of allocator have been fixed if you build in C++20 mode.

I would suggest waiting for grpc / abseil to be updated, perhaps applying those fixes yourself in the mean time.

I was able to fix all the issues related to linking built libwebrtc.a and the built executable works.

Could someone tell me other way to debug errors 1,2 and 3 as the symbols are there in libwebrtc.a

Was using cxx_std_17 and the required was cxx_std_14

The issue lies in usage of cxx_std_17. In the code that I was building has used certain methods which were not available with default cxx_std_11 so I just used cxx_std_17 but it caused a lot of issues with libwebrtc.a. Even though webrtc style guide says that the code is valid c++17 but faced issues. In the same style guide it's mentioned that webrtc code is written is c++14 and that gave me idea to switch to cxx_std_14 and the errors resolved. As mentioned in same webrtc style guide that "Some older parts of the code violate the style guide in various ways." so I think some older code is there which caused the errors

What could be the reason that linker error 1 and 3 refer to .cpp file opposed to .o file as in error 2

I think the reason behind .cpp or .o is that if error originated in my code then it shows .cpp but if it's in 3rd party library, as was the case with a few linker errors which originated from libwebrtc.a, then it shows the error in .o file as the library only has compiled files

how to find ninja target for webrtc build to resolve error 4's undefined reference?

Issue was with the commit I was trying to build.

From webrtc release notes I found out the stable m77 branch head commit and found out the commit I was using didn't have the functions the linker error was referring to but the head commit of stable m77 branch have those functions.

NOTE: In general to get the target which has the .o file with the required symbol we just need to do grep and it will list out where the symbol related function is defined and ninja -t targets all will display all the targets. So just go to corresponding .ninja file and copy all the .o files to the webrtc.ninja and build the libwebrtc.a again.

The problem is actually with the project you use via find_package() and with its package file (/usr/lib64/cmake/grpc/gRPCConfig.cmake in your case). The error message

Defining _HAS_DEPRECATED_RESULT_OF and _SILENCE_CXX17_RESULT_OF_DEPRECATION_WARNING should more granularly restore result_of and turn off its deprecation warning.

_HAS_FEATURES_REMOVED_IN_CXX20 and _SILENCE_ALL_CXX17_DEPRECATION_WARNINGS should do the same for all C++17 features retired in C++20.

Given past history, these "deprecation overrides" should be relatively safe to use now and for some time coming. Below is an older quote (about VS 2017) from an MS sanctioned blog.

5. (Important!) It’s very likely that you’ll encounter source breaking changes in third-party libraries that you can’t modify (easily or at all). We try to provide escape hatches so you can restore removed features or silence deprecation warnings and get on with your work, but first, please report such issues to the relevant library maintainers. By helping them update their code, you’ll help many more C++ programmers just like you.