fix: build release binaries on an older glibc, and refuse to ship a bad one

[blitss]

The 0.4.0 linux artifacts do not load on Debian bookworm:

could not load library ".../typeid.so": /lib/x86_64-linux-gnu/libc.so.6:
version `GLIBC_2.38' not found

bookworm is the base for cloudnative-pg and the official postgres images, so the release is effectively unusable there. It took down a production database that installs the extension from the latest release.

Cause

The move off BuildJet in #29. Those runners were Ubuntu 22.04 (glibc 2.35); ubuntu-latest is 24.04 (glibc 2.39).

glibc is backward but not forward compatible: the linker records a minimum version per symbol, and the loader refuses anything it cannot satisfy. Three symbols crossed the line:

__isoc23_sscanf   GLIBC_2.38
pidfd_getpid      GLIBC_2.39
pidfd_spawnp      GLIBC_2.39

The first is the subtle one. Nothing asked for a C23 API — from glibc 2.38 the headers redirect plain sscanf to __isoc23_sscanf, so ordinary code picks up a 2.38-only symbol purely from the build host's headers. No source change involved.

Fix

Linux release jobs build on ubuntu-22.04 / ubuntu-22.04-arm. glibc 2.35 loads on bookworm (2.36), trixie (2.41) and anything newer. The rule is to build against the oldest runtime supported, not the newest available.

The guard

Compilation and linking succeed either way — this only fails at dlopen on the target, which no test in this repo reaches. A green CI told me nothing. So the release now inspects the built object and fails if any symbol needs more than glibc 2.35:

Requires: GLIBC_2.2.5 ... GLIBC_2.34
OK: highest requirement is 2.34

Verified against both binaries before committing:

object	highest requirement	result
0.3.0 (BuildJet 22.04)	2.34	PASS
0.4.0 (ubuntu-24.04)	2.39	FAIL

Version

Released as 0.4.1 — 0.4.0 is already published and republishing different binaries under the same version would be worse. The upgrade script is empty; nothing about the schema changed.

🤖 Generated with Claude Code