Cannot build with Fedora-provided dependencies

[Demi Marie Obenour]

Fedora doesn’t ship Bazel, and cmake complains about various missing targets.

[happyCoder92]

Could you provide more details about the error/missing targets?
AFAIR deps for Fedora were only provided in a github issue comment and that might be out of date.

[Christian Blichmann]

I was able to build with CMake on Fedora 35 using these dependencies:

sudo dnf install git make automake patch glibc-static libstdc++-static \
  cmake ninja-build python3 python3-pip clang-devel libcap-devel
pip3 install absl-py clang

We'll update the documentation with instructions for Fedora eventually. But only after we have a CI build that runs Fedora.

[Demi Marie Obenour]

@cblichmann did you disable all of the various download options?

[Christian Blichmann]

Define "various download options"? The CMake build system will still download libffi, libunwind, gflags, glog and protobuf.

[Demi Marie Obenour]

Define "various download options"? The CMake build system will still download libffi, libunwind, gflags, glog and protobuf.

Those can all be disabled with various CMake variables. When I do that (so I can use the system versions) the build fails.

[Christian Blichmann]

Alright, can you post the exact CMake command-line you used and the full output as well? Which version of Fedora are you on?

[Demi Marie Obenour]

I’m on Fedora 35. I will post the exact command I used later.

[Christian Blichmann]

We have a GibHub CI build that uses Fedora 35 now.

[Demi Marie Obenour]

Closing under the assumption that using OS-provided versions of libffi, libunwind, gflags, glob, and protobuf is not a supported configuration.

[Demi Marie Obenour]

Script used:

#!/bin/bash --
set -eu
unset v u i do_configure
case $0 in (/*) cd "${0%/*}/";; (*/*) cd "./${0%/*}";; (*) :;; esac
do_configure=0
if [ "${1-}" = --configure ]; then
  do_configure=1
  shift
fi
if [ ! -f build/build.ninja ]; then
  mkdir -p -m 0700 -- build
  do_configure=1
fi
cd build
declare -a v u
v=(ABSL GOOGLETEST GFLAGS GLOG PROTOBUF LIBUNWIND LIBCAP LIBFFI ZLIB)
for i in "${v[@]}"; do
  u+=("-DSAPI_DOWNLOAD_$i:BOOL=OFF")
done

if [ "$do_configure" = 1 ]; then
cmake -GNinja \
	-DSAPI_ENABLE_TESTS:BOOL=ON \
        -DSAPI_ENABLE_EXAMPLES:BOOL=ON \
	-DSAPI_ENABLE_CONTRIB_TESTS:BOOL=ON \
	-DCMAKE_C_COMPILER:PATH=/usr/bin/gcc \
	-DCMAKE_CXX_COMPILER:PATH=/usr/bin/g++ \
        -DCMAKE_MAKE_PROGRAM:PATH=/usr/bin/ninja \
        -DSAPI_ENABLE_GENERATOR:BOOL=ON \
        -DBUILD_SHARED_LIBS:BOOL=OFF \
        "${u[@]}" \
	..
fi
exec ninja "$@"

Error message:

CMake Error at cmake/SapiDeps.cmake:17 (message):
   SAPI: compiling Sandboxed API requires a gtest
                     CMake target in your project
Call Stack (most recent call first):
  cmake/SapiDeps.cmake:48 (sapi_check_target)
  CMakeLists.txt:66 (include)


-- Configuring incomplete, errors occurred!
See also "/home/user/sandboxed-api/build/CMakeFiles/CMakeOutput.log".

[Christian Blichmann]

Disabling the downloading of the third party dependencies is not really tested. For some, like GoogleTest (and Abseil LTS) as well as Protobuf, I suppose it can be made to work, but other (libunwind) need special build settings. And gflags will likely be problematic as well (it'll conflict with the version shipped with GoogleTest and enabled in system builds).
That said, we can improve on the way we check for GoogleTest. Using the system installed version does not define the target that we're looking for.

[Demi Marie Obenour]

Disabling the downloading of the third party dependencies is not really tested. For some, like GoogleTest (and Abseil LTS) as well as Protobuf, I suppose it can be made to work, but other (libunwind) need special build settings. And gflags will likely be problematic as well (it'll conflict with the version shipped with GoogleTest and enabled in system builds). That said, we can improve on the way we check for GoogleTest. Using the system installed version does not define the target that we're looking for.

From the perspective of Linux distribution maintainers, it would be great if:

• Everything that could use system packages, did use system packages.
• The stuff that could not use system packages was bundled in release tarballs, and had its symbols renamed so that it would not clash with the system-provided versions.
• Building SAPI as a shared library was tested in CI.

Every distribution I know of has a strict “no network access during build” policy, and I would rather distributions not need to patch SAPI for this to work.

[Christian Blichmann]

[...]
From the perspective of Linux distribution maintainers, it would be great if:

• Everything that could use system packages, did use system packages.

That'd imply that we'd have more extensive coverage for multiple distributions and package versions.

• The stuff that could not use system packages was bundled in release tarballs,

That's actually what the FETCHCONTENT_FULLY_DISCONNECTED setting is for. Together with FETCHCONTENT_SOURCE_DIR_<uppercaseName>, this can be used for fully offline builds. I have set this up for another project already, we just haven't gotten around to doing it for SAPI.

and had its symbols renamed so that it would not clash with the system-provided versions.

I believe that is what Abseil LTS does.

• Building SAPI as a shared library was tested in CI.

Another culture clash with Google internals: at Google, we build everything in what we call "mostly static" mode. That is, link everything statically, except libc, libm, libdl and libpthread (IIRC there may be others).

Every distribution I know of has a strict “no network access during build” policy, and I would rather distributions not need to patch SAPI for this to work.

And that is the only sane way to do it, of course. What I meant by "it not really tested", is just that -- we don't have a CI setup for this (yet).