Can't build protobuf-31.1 with cmake and abseil-cpp-20250512.0

[arnej27959]

What version of protobuf and what language are you using? Version: 31.1 Language: C++ What operating system (Linux, Windows, ...) and version? Linux, Ubuntu 24.10

What runtime / compiler are you using (e.g., python version or gcc version) gcc version 14.2.0 (Ubuntu 14.2.0-4ubuntu2) cmake version 3.30.3

What did you do? Steps to reproduce the behavior:

1. wget https://github.com/abseil/abseil-cpp/releases/download/20250512.0/abseil-cpp-20250512.0.tar.gz
2. tar xzf abseil-cpp-20250512.0.tar.gz
3. cmake -S abseil-cpp-20250512.0 -B build.absl -DCMAKE_CXX_STANDARD=20 -DCMAKE_INSTALL_PREFIX=$HOME/temp
4. cmake --build build.absl -j 8
5. make -C build.absl install
6. wget https://github.com/protocolbuffers/protobuf/releases/download/v31.1/protobuf-31.1.tar.gz
7. tar xzf protobuf-31.1.tar.gz
8. cmake -S protobuf-31.1 -B build.protobuf -DCMAKE_CXX_STANDARD=20 -DCMAKE_INSTALL_PREFIX=$HOME/temp

What did you expect to see cmake should succeed

What did you see instead?

-- The C compiler identification is GNU 14.2.0
-- The CXX compiler identification is GNU 14.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- protobuf version: 31.1.0
-- Performing Test protobuf_HAVE_LD_VERSION_SCRIPT
-- Performing Test protobuf_HAVE_LD_VERSION_SCRIPT - Success
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Found ZLIB: /usr/lib/aarch64-linux-gnu/libz.so (found version "1.3.1")
-- Performing Test protobuf_HAVE_BUILTIN_ATOMICS
-- Performing Test protobuf_HAVE_BUILTIN_ATOMICS - Success
-- Configuring done (1.6s)
CMake Error at cmake/tests.cmake:91 (target_link_libraries):
  Target "libtest_common" links to:

    absl::scoped_mock_log

  but the target was not found.  Possible reasons include:

    * There is a typo in the target name.
    * A find_package call is missing for an IMPORTED target.
    * An ALIAS target is missing.

Call Stack (most recent call first):
  CMakeLists.txt:333 (include)
... [ error messsage repeats] ...
-- Generating done (0.2s)
CMake Generate step failed.  Build files cannot be regenerated correctly.

Anything else we should know about your project / environment There's no other absl or protobuf libraries installed.

I checked that cmake found the just-compiled absl configuration:

$ grep absl build.protobuf/CMakeCache.txt 
//The directory containing a CMake configuration file for absl.
absl_DIR:PATH=/home/arnej/temp/lib/cmake/absl

Workaround: add -Dprotobuf_BUILD_TESTS=OFF to cmake command line.

[mkruskal-google]

The root problem here is that you installed Abseil without -DABSL_BUILD_TEST_HELPERS=ON, and also tried to build our tests (which use those helpers). I think one option to make this a little more user-friendly might be to automatically disable protobuf_BUILD_TESTS when the test helpers can't be found, but the problem remains if you actually want to build tests.

Note: installing protobuf directly will also install abseil if it's not present and set that flag when appropriate

[flipkickmedia]

Im also suffering from this problem. There is very little documentation on how to link Abseil correctly and AFAIK the compile process is broken.

If you look into protobuf/cmake/abseil-cpp.cmake there is some notion that Abseil can be downloaded but this is never triggered.

My cmake command was cmake . -DCMAKE_CXX_STANDARD=20 -DCMAKE_INSTALL_PREFIX=/home/tshaw/Documents/entitywind-node-c/deps

abseil-cpp resides in deps.

There are no warnings from the cmake output about the location of where is being searched.

This leaves me to believe that the documentation is severely out of date and needs work. If some work could be done to prompt the user to add in specific params to make the process brainless. It should just work.

For example:

tshaw@laptop-entitywind:~/Documents/entitywind-node-c/deps/protobuf$ cmake . -DCMAKE_CXX_STANDARD=20
-- protobuf version: 31.1.0
-- Could NOT find GTest (missing: GTest_DIR)
-- Fallback to downloading GTest 1.15.2 from GitHub
-- Could NOT find absl (missing: absl_DIR)
-- Fallback to downloading Abseil 20250127.0 from GitHub
-- Configuring done (0.5s)
-- Generating done (0.3s)
-- Build files have been written to: /home/tshaw/Documents/entitywind-node-c/deps/protobuf

No mention on the internet of GTest_DIR or absl_DIR or any mention in the docs.

Maybe the OP would be able to bypass his problems if he could pass those params.

[skull-squadron]

How is Arch building correctly then? Packaged absl with DABSL_BUILD_TEST_HELPERS=ON ? Different compiler (gcc)? I'm using the default clang/++ and lld 14 on Debian with two methods rather than a hermetic toolchain of any sort:

• Github-downloaded absl that results in missing symbols
• system absl results in cmake find_package errors

-DCMAKE_CXX_STANDARD=20 seems like a terrible idea because that's changing the C++ standard. Dependencies variably use 14 and 17.

Bazel build works correctly, but it's so opaque, undocumented, and complicated that I can't find a way to have it generate shared and static libraries, and make install.

[mkruskal-google]

If you look into protobuf/cmake/abseil-cpp.cmake there is some notion that Abseil can be downloaded but this is never triggered.

We somewhat recently simplified our cmake setup to make it a little more "brainless". The logic is that it will look for a system install, and if it can't find one it'll download a pinned version from github and use that. The protobuf_FORCE_FETCH_DEPENDENCIES override can force this fetch of dependencies over any pre-existing installs, but our assumption is that if you have Abseil installed you'd want that one used.

How is Arch building correctly then? Packaged absl with DABSL_BUILD_TEST_HELPERS=ON ? Different compiler (gcc)? I'm using the default clang/++ and lld 14 on Debian with two methods rather than a hermetic toolchain of any sort:

Github-downloaded absl that results in missing symbols system absl results in cmake find_package errors -DCMAKE_CXX_STANDARD=20 seems like a terrible idea because that's changing the C++ standard. Dependencies variably use 14 and 17.

Bazel build works correctly, but it's so opaque, undocumented, and complicated that I can't find a way to have it generate shared and static libraries, and make install.

I would assume they build with -Dprotobuf_BUILD_TESTS=OFF, which doesn't build our tests and therefore doesn't require Abseil's test helpers. Bazel doesn't support any kind of "install". I believe there are ways to control static/shared linkage, but generally the idea is that you'd use Bazel to build your binaries rather than ours.

[skull-squadron]

I was tired and confused, and meant to correct my mistakes. The cmake build finally worked out after way too many tries. absl needs to be built on Debian because the stable one is as old as the dinosaurs.

On Fri, Jul 25, 2025 at 10:06 PM Mike Kruskal @.***> wrote:

mkruskal-google left a comment (protocolbuffers/protobuf#22209) https://github.com/protocolbuffers/protobuf/issues/22209#issuecomment-3121075094

If you look into protobuf/cmake/abseil-cpp.cmake there is some notion that Abseil can be downloaded but this is never triggered.

We somewhat recently simplified our cmake setup to make it a little more "brainless". The logic is that it will look for a system install, and if it can't find one it'll download a pinned version from github and use that. The protobuf_FORCE_FETCH_DEPENDENCIES override can force this fetch of dependencies over any pre-existing installs, but our assumption is that if you have Abseil installed you'd want that one used.

How is Arch https://gitlab.archlinux.org/archlinux/packaging/packages/protobuf/-/blob/main/PKGBUILD?ref_type=heads building correctly then? Packaged absl with DABSL_BUILD_TEST_HELPERS=ON ? Different compiler (gcc)? I'm using the default clang/++ and lld 14 on Debian with two methods rather than a hermetic toolchain of any sort:

Github-downloaded absl that results in missing symbols system absl results in cmake find_package errors -DCMAKE_CXX_STANDARD=20 seems like a terrible idea because that's changing the C++ standard. Dependencies variably use 14 and 17.

Bazel build works correctly, but it's so opaque, undocumented, and complicated that I can't find a way to have it generate shared and static libraries, and make install.

I would assume they build with -Dprotobuf_BUILD_TESTS=OFF, which doesn't build our tests and therefore doesn't require Abseil's test helpers. Bazel doesn't support any kind of "install". I believe there are ways to control static/shared linkage, but generally the idea is that you'd use Bazel to build your binaries rather than ours.

— Reply to this email directly, view it on GitHub https://github.com/protocolbuffers/protobuf/issues/22209#issuecomment-3121075094, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABWYMGQIUGNOQIGR657L3D3KLWEBAVCNFSM6AAAAAB7ES6VLKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCMRRGA3TKMBZGQ . You are receiving this because you commented.Message ID: @.***>

[doganulus]

There are several use case where a more grained absl build is desired. I may go a separate absl build but then I have to track the version used by the protobuf. Here is some improvements to get absl from protobuf.

First, a combined absl target to build and install all absl protobuf dependencies (listed under the protobuf_ABSL_USED_TARGETS variable defined in cmake/abseil-cpp.cmake). This variable is not available externally and I couldn't find a way to separate builds unless listing every absl target from the command line.

Second, I want a static build for absl while I want shared libraries for libprotobuf and libprotobuf-lite.

Third, I do not want to install absl libraries when installing shared protobuf libraries. The current setup does not allow easy-overriding absl_ENABLE_INSTALL if protobuf_ENABLE_INSTALL is ON.

[hartwork]

I would like to note that this affects the default build configuration (plain cmake -S . -B build) and that four months after the report the default build configuration is still broken.