Why

The scalable-topics SDK (pulsar::st, #598) targets C++20 — it uses concepts, coroutine-awaitable Future<T>, and using enum. The last of these needs GCC 11+. The package-build images shipped older compilers, so two package jobs failed compiling the C++20 examples:

• RPM — rockylinux:8 ships GCC 8.5, which has no -std=c++20 (CMake falls back to -std=c++2a, __cplusplus=201709), so the Cxx20.h guard #errors.
• Deb — debian:11 ships GCC 10, which clears the guard but lacks using enum (a GCC 11 feature), so it fails to compile Error.h.

This bumps the package-build toolchains to GCC 11+ while preserving distro compatibility where it matters.

What changed

For the RPM I deliberately kept the el8 base so the published RPM still runs on RHEL/Rocky/CentOS 8 (glibc 2.28). gcc-toolset-12 provides GCC 12 against the el8 ABI; it's enabled in the spec %build with source /opt/rh/gcc-toolset-12/enable, and ships its own static libstdc++ for the static libpulsar.a. The Debian image had no equivalent (bullseye can't install GCC 11+ from its repos), so it moves to debian:12 — i.e. the deb artifact now requires Debian 12+, while the RPM keeps el8 support.

Verification

Done locally against the real toolchains, not just a syntax check:

• Built both images from the updated Dockerfiles — all packages resolve on the new bases; gcc-toolset-12 installs alongside the el8 powertools/devel repos.
• Compiled all four pulsar::st examples with -std=c++20 -Wextra -Werror under debian:12 (GCC 12.2.0) and gcc-toolset-12 on rockylinux:8 (GCC 12.2.1) — all pass.
• Confirmed . /opt/rh/gcc-toolset-12/enable works under /bin/sh (what rpmbuild's %build uses) and that the toolset provides a static libstdc++.a for -static-libstdc++.

Notes

• This is the prerequisite that unblocks the package-build jobs on #598. The library itself remains C++17; only the new pulsar::st code requires C++20.
• apk/Alpine already ships GCC 13, so it needed no change.