#794 removed the std::random_device uses, so libstdc++'s getentropy reference
no longer enters the link and the last symbol above 2.17 is gone. With expf
already pinned per architecture, the artifact requires nothing newer than the
glibc that EL7 ships.

Measured on release builds in the AlmaLinux 8 image on both architectures: no
references above 2.17 at all, and the floor check passes at 2.17 where it
previously named getentropy@GLIBC_2.25. Both artifacts also load on Oracle
Linux 7.9 (glibc 2.17) with no unresolved symbol versions, which tests the
dynamic linker rather than the symbol table.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

… EOL Debian (#790)

* ci: drop the archived buster base default, bump the amd64 build image

The x64-2.17 image's Dockerfile defaulted to openjdk:11-slim-buster. Debian 10
buster left even LTS support in June 2024 and its repositories are archived, so
`apt-get update` against them now fails with "does not have a Release file" --
and rebuild-images.sh builds without --build-arg BASE_IMAGE whenever
BASE_IMAGE_LIBC_2_17 is unset, which reaches that default. The body of the file
is yum-based, so a Debian base cannot work there at all; the default now names
what CI actually passes (centos:7), with the glibc 2.17 rationale for staying
on an EOL distro recorded next to the vault mirror URLs it already needs.

The amd64 build image moves to Debian 13 trixie, the current stable release.
It compiles no shipped native code -- build:x64 uses the glibc 2.17 image -- so
its glibc is not a customer-facing floor. The arm64 image stays on bullseye: it
is where build:arm64 compiles the shipped linux-arm64 libjavaProfiler.so, so
that glibc (2.31) is the runtime floor for arm64 customers and trixie would
raise it to 2.41. Both variables now say which of the two they are and why.

Also drop the `|| true` from the base image's package install, and with it the
dead `apk` branch -- Alpine has its own Dockerfile.musl. As written, a total
install failure produced a "successful" image whose tools were simply missing,
surfacing later as an unrelated job failure.

Verified against the real archives: buster's apt repositories fail as
described, bullseye's still resolve, and the full package list installs on
trixie with hexdump present (bsdmainutils is still a real package there).

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

* ci: build the shipped binaries on AlmaLinux 8 with gcc-toolset-14

Release builds link -static-libstdc++ -static-libgcc, so the C++ runtime and
unwinder in the shipped libjavaProfiler.so come out of the build image's
toolchain. That makes the build image's support status a property of the
artifact, not just of CI: on CentOS 7 those objects can never receive another
security rebuild, and no gcc newer than devtoolset-10 was ever built for
aarch64 there (the dts-11 collection ships binutils, elfutils and its own
metapackage for aarch64, but no compiler).

AlmaLinux 8 with gcc-toolset-14 is supported until 2029 and publishes the
toolset for x86_64 and aarch64 alike, so one image definition now covers both
architectures with one compiler version, replacing the hand-rolled CentOS 7
image and its vault/Rocky mirror repositories. almalinux:8 is a multi-arch
manifest, so a single BASE_IMAGE_GLIBC serves both.

Measured on the real artifact, built in this image for both architectures:

  max required symbol version   GLIBC_2.27  (both x86_64 and aarch64)
  symbols above 2.17            expf (2.27), getentropy (2.25)
  dynamic dependencies          libc, libdl, libm, libpthread, librt
  GLIBCXX/CXXABI references     none

So the runtime floor moves 2.17 -> 2.27, not to the base image's 2.28: symbol
versions are per-function. 2.27 keeps Ubuntu 18.04 (glibc 2.27) in support and
drops RHEL 7 (2.17), Amazon Linux 2 (2.26) and SLES 15 SP1 (2.26). Both
symbols are addressable with a .symver pin if a lower floor is needed later.

With the shipped arm64 build moved off the Debian image, that image no longer
sets a customer-facing floor, so it moves to trixie alongside amd64 -- which
also restores apt on the arm64 sanitizer jobs.

Names now describe the purpose rather than a version that has changed twice:
BUILD_IMAGE_{X64,ARM64}_GLIBC and BASE_IMAGE_GLIBC, with tag suffixes
{x64,arm64}-glibc-base. The variables still hold the current images until
rebuild-images.sh publishes the new tags.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

* ci: move the C++ test toolchain into the build image

The sanitizer jobs installed cmake, libgtest-dev, libgmock-dev, binutils,
libc6-dbg and llvm in a before_script, which made every run depend on the
distro archive still serving them, and which does not survive the move to
trixie: sanitizer/asan_interface.h is no longer part of the llvm package
there, so compiling linearAllocator.cpp fails with

  fatal error: 'sanitizer/asan_interface.h' file not found

The header comes from libclang-rt-<n>-dev. The packages now live in the image
instead, using the unversioned libclang-rt-dev metapackage so the right clang
runtime is picked up on whatever release the image is built from.

Dropping the before_script override also stops these jobs bypassing the
pipeline default, so they get the CANCELLED guard and the maven proxy export
that every other job already had.

Verified on a locally built trixie image (clang 19.1.7, gtest 1.16.0),
aarch64: buildGtestAsan and buildGtestTsan both compile, and all 62 asan and
62 tsan binaries pass.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

* ci: repin the build images onto the rebuilt bases

Pins from the rebuild in pipeline 137281788, which built every image from the
definitions on this branch. Verified by pulling each digest:

  x64-glibc-base    AlmaLinux 8.10, glibc 2.28, gcc 14.2.1
  arm64-glibc-base  AlmaLinux 8.10, glibc 2.28, gcc 14.2.1
  x64-base          Debian 13 trixie, glibc 2.41, clang 19.1.7
  arm64-base        Debian 13 trixie

The musl, datadog-ci and benchmark images come from the same rebuild; their
definitions did not change on this branch.

These pins belong here rather than in the image-update PR the rebuild opened
against main: main has no BUILD_IMAGE_*_GLIBC variables, so the two
shipped-binary pins silently did nothing there, while BUILD_IMAGE_ARM64 -- which
main still uses for build:arm64 and stresstest:arm64 -- would have moved the
shipped arm64 binary onto a trixie image and its glibc 2.41 floor.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

* ci: point the base image's default at the release CI actually uses

The ARG default was still the bullseye digest while both OPENJDK_BASE_IMAGE
variables moved to trixie, and the comment justified it as "the more
conservative of the two" for an arm64 glibc floor that no longer exists here:
the shipped binaries come from .gitlab/base/el8/Dockerfile, so neither arch of
this image sets a customer floor.

It also stopped being a harmless default. With the package install no longer
ending in `|| true`, a direct `docker build` of this file -- or
rebuild-images.sh reaching its documented unset-variable fallback -- hit
bullseye's pruned security pool and failed on exactly the 404s this PR exists
to fix. Verified: building with no BASE_IMAGE argument now produces a trixie
image.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

* ci: assert the shipped library's ABI floor in the build job

The oldest host the shipped library can load on is decided entirely by the
build image: the highest versioned glibc symbol it references sets the glibc
floor, and the static-link flags decide whether it needs a C++ runtime from
the host at all. Nothing checked either, so both could move without a source
change and without a failing job.

check-abi-floor.sh asserts both against SHIPPED_GLIBC_FLOOR, declared in
config.env next to the image pin that determines it, and build.sh runs it on
each glibc artifact before the job ends. musl targets carry no glibc symbol
versions and are skipped. Failures name the offending symbols or libraries,
since the point of the check is to say what needs fixing.

Three cases fail loudly rather than reporting a pass: an artifact with no
versioned glibc symbols, one with no NEEDED entries, and a sort that cannot
order versions. Each would otherwise leave the check quietly inoperative,
which is worse than not having it.

The checker reads the artifact through $OBJDUMP, so its tests drive it with
canned output and need no compiler or real shared object; they run in a new
ci-script-tests job alongside shellcheck. Every guard was mutation-checked:
disabling it individually turns a named assertion red.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

* ci: pin expf to its GLIBC_2.17 interface and tighten the floor to 2.25

glibc 2.27 added a faster expf under a new symbol version and made it the
default, so building on AlmaLinux 8 made the shipped library require
expf@GLIBC_2.27 from source that has not changed. glibcCompat.h selects the
GLIBC_2.17 interface explicitly, which is still exported and still maintained;
.symver picks which of the versions already in the host's libc is called and
bundles nothing, so a host on a newer glibc still runs its own implementation.

Measured on the AlmaLinux 8 + gcc-toolset-14 build: expf moves from
GLIBC_2.27 to GLIBC_2.17 and the artifact's requirement drops from 2.27 to
2.25, so the floor follows to 2.25. The remaining above-2.17 symbol is
getentropy, which libstdc++ references from its own std::random_device and
which glibc exports in only one version -- no pin can reach it, so 2.17 waits
on removing the std::random_device uses.

The pin is guarded to glibc: musl has no symbol versioning and a .symver
naming a GLIBC_* version fails to link there, which would have broken both
musl targets. Verified by linking and running a TU that reaches expf through
poissonSampler.h under musl, where it emits no GLIBC_ references at all.

The floor check could not read the artifact the pin produces. objdump
parenthesises a binding to a non-default version, which is exactly what
.symver creates, and the parser matched only the bare form -- so it found no
versioned references on a pinned library. The empty-result guard turned that
into a loud failure rather than the silent pass it would otherwise have been,
which is what it exists for. The parser now accepts both forms, with fixtures
for a pinned artifact at and above the floor.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

* ci: pin expf per architecture and run both script suites through bash

The expf pin named a version that does not exist on x86_64, so every link
against it failed there:

  nativeSocketSampler.o: undefined reference to `expf@GLIBC_2.17'
  no symbol version section for versioned symbol `expf@GLIBC_2.17'

A symbol's oldest version is the baseline of the glibc release that introduced
the port, which differs per architecture: x86_64 has expf@GLIBC_2.2.5 and
aarch64 expf@GLIBC_2.17, both alongside the GLIBC_2.27 default added in 2.27.
Naming a version the architecture does not export is a link error rather than a
fallback, so the pin now selects per architecture and an unlisted one gets no
pin at all, leaving the ABI floor check to report what it requires.

This took out every x86_64 job that links the library: the two sanitizer gtest
builds, and the CodeQL and Analyze jobs, which build linkRelease.

Verified by linking and running a translation unit that reaches expf through
poissonSampler.h under clang on Debian trixie -- the toolchain the sanitizer
jobs use -- on both architectures, and by building the release artifact on
AlmaLinux 8 for both: expf binds to each architecture's oldest version,
getentropy@GLIBC_2.25 is the only remaining reference above 2.17, and the floor
check passes at the declared 2.25 on both.

Separately, ci-script-tests invoked the test suites directly. includes_test.sh
is not executable and documents being run through bash, so the job failed with
exit 126 after its own assertions had all passed. Both suites now run through
bash, which leaves the existing file's mode alone.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

* ci: lower the shipped floor to 2.17 now that getentropy is gone

#794 removed the std::random_device uses, so libstdc++'s getentropy reference
no longer enters the link and the last symbol above 2.17 is gone. With expf
already pinned per architecture, the artifact requires nothing newer than the
glibc that EL7 ships.

Measured on release builds in the AlmaLinux 8 image on both architectures: no
references above 2.17 at all, and the floor check passes at 2.17 where it
previously named getentropy@GLIBC_2.25. Both artifacts also load on Oracle
Linux 7.9 (glibc 2.17) with no unresolved symbol versions, which tests the
dynamic linker rather than the symbol table.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

---------

Co-authored-by: Claude Opus 5 (1M context) <[email protected]>