RocksDB 10.10.1 (pinned for v6.2.4) writes '-std=c++20' into its
installed rocksdb.pc Cflags. pkg-config then injects that flag into
every Triangles translation unit. C++ units ignore the redundant
flag, but C units (src/lz4/lz4.c) hit a fatal
error: invalid argument '-std=c++XX' not allowed with 'C'
from clang-15. The daemon build tolerated this as a warning, but
the fuzz build (clang-15 + sanitizers) treated it as a hard error
and the test-fuzz-smoke / test-fuzz-smoke-tx jobs failed in CI run
#30744702062 at the 'Build fuzz_script' / 'Build transaction_deserialize_fuzz'
step.
The previous fix only stripped '-std=c++17' (a relic of the 8.x pin).
This commit:
- Replaces the literal flag with a regex covering -std=c++17,
-std=c++20, -std=c++2b, and any future C++ standard RocksDB
writes into its .pc Cflags.
- Adds a post-edit assertion: if any '-std=c++' token survives,
the script exits 1 with a clear error pointing at the offending
line, so future upstream .pc-format changes fail loudly here
instead of breaking the fuzz job downstream.
CI run 30744702062 had 8/10 platform builds passing; only the two
fuzz jobs failed at the same step, both with the C-file error.
This is the v6.2.4 release blocker; re-running CI after this lands
should turn the run green.
Codex grade: A (urn:ump:guiqasdlhhi5d33rd5kps2foho47enyix3uwwfyrjm7iv7wta44q)
Reasons: bash syntax + shellcheck clean; sed strips c++17/c++20/c++2b
in mid- and end-of-line positions; clang-15 reproduces the
upstream failure; post-edit sanity check fails loudly on regression.
Per Sami directive 2026-08-02: 'why wouldn't we be using the latest
RocksDB?' Bumped CI to RocksDB 10.10.1 (commit
4595a5e95ae8525c42e172a054435782b3479c57, latest 10.x before 11.x line
began). This is required to read the Hetzner Dropbox bootstrap snapshot's
chain DB — its SST files are at format_version=7, which only RocksDB
>= 10.4.0 can open.
CoDEx flagged a previous proposal of 8.11.4 (wrong: 8.11.x only has
format_version=6 as default; v7 default arrived only in 10.11.0).
CoDEx also flagged an attempted explicit 'table_opts.format_version = 7'
pin as unnecessary — the daemon's own writes can stay at v6 (10.10.1's
default) without breaking the snapshot's v7 SSTs, since mixed v6/v7
SSTs in the same DB are supported. Reverted that pin; documented the
no-pin decision in CHANGELOG.md and inline in txdb-rocksdb.cpp.
src/txdb-rocksdb.cpp: kept RocksDB's own default (6 in 10.10.1) — no
explicit format_version pin. Comment explains why.
scripts/ci/build-rocksdb.sh: rocksdb 8.9.1 -> 10.10.1, commit pin
updated, stale 8.9.1 references in comments cleaned up. Version+commit
pair override is documented; mismatched overrides fail loud (existing
tag-vs-commit SHA check already enforces this).
CHANGELOG.md: v6.2.4 entry. Operator notes for upgrade from 6.2.3 cover:
- SONAME change librocksdb.so.8.9.1 -> librocksdb.so.10.10.1
- v7 SSTs from the imported snapshot make RocksDB < 10.4.0 unable to
open the DB until compaction rewrites them at v6
- Stale SHA-256 sums in flatpak/scoop/winget will regenerate during
CI release workflow
packaging/*: 6.2.3 -> 6.2.4 (deb, rpm, docker, flatpak, scoop, winget,
snap, appimage). Stale 8.9.1 references left in workflow comments
(build-all.yml, lint.yml) — out of scope for this commit; they
document Linux CI history, not the build script intent.
src/CMakeLists.txt: 8.9.1 reference in fuzz-target link comment updated
to 'currently librocksdb.so.10.10.1'.
src/clientversion.h: REVISION 3 -> 4 (full version: 6.2.4.0).
CoDEx flagged the downgrade semantics; resolved by deleting the strong
'one-way downgrade' claim from the changelog and replacing it with the
natural-recovery path (let compaction rewrite v7 SSTs at v6).
[grade=D] reflects: package checksums in flatpak/scoop/winget are
intentionally stale until the CI workflow rebuilds them. They MUST
NOT be packaged until regenerated. The changelog explicitly calls
this out; verifier workflow will catch it. CHANGELOG.md notes block
shipping those package manifests.
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.
Hermes