librocksdb-sys: 'uint64_t' has not been declared on GCC 15

Written 10 November 2026

Written 2026-11-10. If a Rust build that depends on rocksdb 0.21 or 0.22 started failing on Ubuntu 26.04 or on GitHub's ubuntu-latest runner, this is the cause. The short answer: move to rocksdb 0.24.0 or later, or set CXXFLAGS="-include cstdint" for the build, or run that job on ubuntu-24.04.

The error

Built with cargo build on ubuntu:26.04 (g++ 15.2.0) on 2026-11-04, with rocksdb = "=0.21.0":

warning: librocksdb-sys@0.11.0+8.1.1: rocksdb/db/blob/blob_file_meta.h:28:7: error: 'uint64_t' has not been declared
warning: librocksdb-sys@0.11.0+8.1.1:    28 |       uint64_t blob_file_number, uint64_t total_blob_count,
warning: librocksdb-sys@0.11.0+8.1.1: rocksdb/db/blob/blob_file_meta.h:15:1: note: 'uint64_t' is defined in header '<cstdint>'; this is probably fixable by adding '#include <cstdint>'
warning: librocksdb-sys@0.11.0+8.1.1: ToolExecError: command did not execute successfully (status code exit status: 1): LC_ALL="C" "c++" ...
error: failed to run custom build command for `librocksdb-sys v0.11.0+8.1.1`

The same lines appear with librocksdb-sys v0.16.0+8.10.0 (rocksdb 0.22.0). Next to them you may also see 'uint64_t' does not name a type and template argument 2 is invalid. The same two crate versions built on ubuntu:24.04 (g++ 13.3.0) with no change.

Why it happens now

GCC 15's C++ library stopped including <cstdint> from other standard headers. The GCC 15 porting notes say so directly: <cstdint> and <stdint.h> "may need to be included explicitly when compiling with GCC 15" (GCC 15 porting guide). Older RocksDB headers such as db/blob/blob_file_meta.h and include/rocksdb/trace_record.h used uint64_t without including it, and librocksdb-sys compiles RocksDB from source with the system c++.

Ubuntu 26.04 ships GCC 15.2, and GitHub is moving the x64 ubuntu-latest label to Ubuntu 26.04 between 2026-10-19 and 2026-11-19 (actions/runner-images#14748). So a workflow that has not changed starts failing on whichever runs land on the new image. More on that move in our Ubuntu 26.04 runner note.

RocksDB added the missing includes upstream in 72c3887 (blob_file_meta.h, 2025-04-28) and 58420b7 (trace_record.h, 2025-06-13). The Rust bindings merged "Support GCC 15" in rust-rocksdb#1007, and both changes ship in rocksdb 0.24.0, which builds RocksDB 10.4.2.

Versions and dates from crates.io, read 2026-11-10. The librocksdb-sys column is the lowest version each crate accepts. rocksdb 0.23.0 asks for ^0.17.1, so a lockfile resolved after 2025-08-10 may already have 0.17.3+10.4.2, and cargo update -p librocksdb-sys may be enough there; we did not build that pair.

The fixes

All three were built in containers from the official ubuntu:26.04 image (g++ 15.2.0) with cargo build and no network, on 2026-11-04 and 2026-11-09. Each one exited 0 and the test program wrote and read a key.

1. Upgrade to rocksdb 0.24.0 or later. This is the real fix. rocksdb = "0.24.0" built on GCC 15 with no flags. It needs Rust 1.85 or newer (its rust-version), and the API changes between 0.21 and 0.24 are in the rust-rocksdb releases. A public example of this bump, merged: anza-xyz/agave#9068 (0.23.0 to 0.24.0).

2. Force the include with CXXFLAGS. When rocksdb 0.21 comes in through another crate you cannot bump, add this to the project's .cargo/config.toml:

[env]
# RocksDB 8.x headers use uint64_t without including <cstdint>; GCC 15 no longer pulls it in.
CXXFLAGS = "-include cstdint"

The cc crate passes it to every C++ file the build script compiles, which is the same as adding #include <cstdint> at the top of each one. With it, rocksdb 0.21.0 and 0.22.0 built on GCC 15.2, and a 0.21 build with the same file still passed on GCC 13.3. In a workflow, setting CXXFLAGS: -include cstdint in the job's env does the same; a public example, merged: tangle-network/blueprint#1668, in release-plz.yml. Cargo's [env] does not override a CXXFLAGS already set in the environment, so if your CI sets its own, add -include cstdint there.

3. Keep the job on Ubuntu 24.04. runs-on: ubuntu-24.04 keeps GCC 13.3, and 8.1.1 builds there unchanged. We have not seen a retirement date for the 24.04 image, but it is a stopgap. Public examples, merged: tangle-network/blueprint#1621 and MystenLabs/deepbookv3#1426.

Docker builds are a separate case. An image built FROM rust:1.9x-bookworm compiles with Debian 12's GCC 12 whatever runner builds it, so it is not affected until the base moves to a release with GCC 15.

Find it in your repos

cargo tree -i librocksdb-sys shows which crates pull it in, and this lists the version in every lockfile of a checkout:

grep -rA1 --include=Cargo.lock 'name = "librocksdb-sys"' .

Anything below 0.17.3+10.4.2 that is built by the system compiler on Ubuntu 26.04, or on a runner image with GCC 15, fails at this step. Other C and C++ crates compiled from source can hit the same header change; the upgrade canary's ubuntu-24.04 and ubuntu-26.04 matrix in the runner note shows them before the label moves.

If this break is in a public repository, we send the fix as a pull request for free; in a private repository it is $300, invoiced after you merge it. To catch the next one before it reaches a release, send your organisation's GitHub name to hello@nonceworks.com and we send back a free report on its public release, publish and nightly workflows (merged fixes, pricing).

Limits

• x86_64 only. We built rocksdb 0.21.0, 0.22.0 and 0.24.0 with cargo and compiled the RocksDB sources of librocksdb-sys 0.17.1+9.9.3 directly; for 0.25.0 the table goes by whether the upstream commits are in the bundled RocksDB.
• We tested GCC 13.3 and 15.2 from the Ubuntu archive. Clang has its own header differences and was not part of these runs.

Sources

• GCC 15 porting guide, "Header dependency changes".
• RocksDB commits 72c3887 and 58420b7, both in v10.4.2; the upstream report rocksdb#13365.
• rust-rocksdb#1007 "Support GCC 15", merged 2025-05-28, released in 0.24.0.
• Runner move: actions/runner-images#14748.