RocksDB's install-shared writes a rocksdb.pc with both:
-isystem third-party/gtest-1.8.1/fused-src
-std=c++17
The previous PR fix scrubbed the bad include path but left -std=c++17.
pkg-config consumers inherit that flag via INTERFACE_COMPILE_OPTIONS,
which propagates to CMake imported targets as a compile option.
Result: Triangles' configure sets CXX_STANDARD 20, but the compile
command line ends up with '-std=c++20 ... -std=c++17' (rocksdb.pc's
flag comes last and wins). GCC reports:
error: defaulted 'bool operator!=...' only available with
'-std=c++20' or '-std=gnu++20'
Strip -std=c++17 from Cflags. Triangles sets its own standard via
CMake; the flag from rocksdb.pc was never useful anyway (consumers
should choose their own standard).
This bug only surfaced now because we replaced librocksdb-dev 6.11.4
with a locally-built RocksDB 8.9.1 — the system package's .pc didn't
have this -std flag, the freshly-built one does.
The previous sed expression had \${prefix} in a double-quoted string,
which bash was expanding to a literal prefix variable lookup. With
`set -euo pipefail` and unbound variables causing exit, the entire
script aborted right after `make install-shared`, before ldconfig
and the sanity check ran.
Use single quotes around the sed expression so bash leaves the
\${prefix} alone for sed to interpret.
Discovered via:
scripts/ci/build-rocksdb.sh: line 57: prefix: unbound variable
RocksDB's Makefile unconditionally appends `-isystem third-party/
gtest-1.8.1/fused-src` to the generated rocksdb.pc Cflags. That path
is relative to the build directory, so when the installed .pc file
ends up in /usr/local/lib/pkgconfig/, Triangles' CMake configure
errors out with:
CMake Error in src/CMakeLists.txt:
Imported target 'PkgConfig::RocksDB' includes non-existent path
'third-party/gtest-1.8.1/fused-src'
Modern CMake (>= 3.27) refuses imported targets with relative paths
in INTERFACE_INCLUDE_DIRECTORIES. Replace the bad flag with an
absolute path to the installed include dir so pkg-config consumers
get a real on-disk path.
Discovered while debugging the second CI failure on PR #10
(Configure succeeded but generation failed because PkgConfig::RocksDB
referenced a path that didn't exist).
The previous sanity check matched against `librocksdb.so.${ROCKSDB_VERSION}`
(full semver like 8.9.1), but `ldconfig -p` only prints major.minor
(e.g. `librocksdb.so.8.9`). The library was correctly installed but
the check failed, killing the CI job before Configure could run.
Check the versioned file on disk first (definitive), then ldconfig with
the major.minor pattern (sanity for runtime linker). Both must pass.
Discovered when investigating CI failure on PR #10.
PR #10 added a configure-time FATAL_ERROR for RocksDB < 7.4.0 because
the v5.9.24 daemon on DNS2 was built against librocksdb 6.11 and can't
read smsgDB SST files written by newer RocksDB (XXH3 per-block
checksum). The check worked — but it immediately failed CI, because
GitHub's ubuntu-22.04 runners also ship librocksdb-dev 6.11.4.
This is the same drift class the original patch was meant to prevent.
Fix: build RocksDB from source in CI, pinned to 8.9.1 (matching DNS2's
system version). Add scripts/ci/build-rocksdb.sh as a reusable helper
and call it from each of the four Linux jobs (test-linux-unit,
test-linux-sanitizers, build-linux-daemon, build-linux-qt). Drop
librocksdb-dev from the apt-get install (otherwise find_library would
pick up /usr/lib/librocksdb.so.6.11.4 first) and add libsnappy-dev /
libzstd-dev / liblz4-dev (compression libs RocksDB optionally links
against).
MacOS was already passing — Homebrew's rocksdb is current. Windows
was already passing — MSYS2's mingw-w64-rocksdb is at 9.x.
Also fix a cosmetic CMake bug: the version-detect function was setting
RocksDB_VERSION with PARENT_SCOPE only, so the 'Detected RocksDB
version from version.h:' message printed an empty value. Set the local
variable too so the STATUS message reflects the real value.
Krystie