Build Linux natives in a debian:11 container so they load on glibc 2.31+

[shannah]

Problem

The published linux_64 / linux_arm64 libwebview.so (checked in 1.8.1 and 1.10.0) are built on the ubuntu-24.04 runners' own toolchain, so they require:

• __isoc23_sscanf@GLIBC_2.38, from the sscanf in src_c/webview.h compiled against glibc ≥ 2.38 headers
• std::ios_base_library_init@GLIBCXX_3.4.32, from GCC 13's <iostream>

System.load fails on Ubuntu 22.04 and 20.04 with version `GLIBC_2.38' not found, so a Linux app built on this library can't open its window there. This is what blocked an agentic-app-framework app on Ubuntu 22.04.

Change

• Both build.yml and maven-release.yml now compile the Linux natives inside a debian:11 container (glibc 2.31, GCC 10). The runners are still ubuntu-24.04 / ubuntu-24.04-arm, so each arch still builds natively. Bullseye's WebKitGTK 2.44 headers keep every WEBKIT_CHECK_VERSION-gated optional feature (2.12 / 2.36 / 2.40) compiled in. WebKit is still loaded at runtime (4.1, falling back to 4.0).
• apt in the container is pinned to the permanent bullseye main suite on archive.debian.org. Bullseye is EOL and its -security pool has already been emptied while its index still lists packages, so an unpinned install fails with 404s. Signatures are still verified; only the expired Valid-Until check is skipped.
• New gate: the build fails if objdump -T shows any symbol newer than GLIBC_2.31, GLIBCXX_3.4.28 or CXXABI_1.3.12. Without it, a future runner-image or code change could raise the requirement again unnoticed.
• README states the glibc 2.31 floor. build-linux.sh notes that a local build has the host's floor, not the shipped one.
• Canvas 8 updated first (Requirements, Approach, Structure, Ops 6/7/8, Safeguards), then regenerated into the files above.

Verification (local, x64)

• Ran the workflow's Linux step as written. New .so maximums: GLIBC_2.14, GLIBCXX_3.4.22, CXXABI_1.3.11. Both gates pass.

• Gate run against the published 1.8.1 .so: fails and lists every offending symbol (2.32–2.38, GLIBCXX 3.4.29–3.4.32, CXXABI 1.3.13).

• System.load in stock containers:

  • Ubuntu 20.04 (WebKitGTK 4.0, 2.38.6): new loads; 1.8.1 fails with GLIBC_2.32 not found
  • Ubuntu 22.04 (4.1, 2.50.4): new loads; 1.8.1 fails with GLIBC_2.38 not found
  • Ubuntu 24.04 (4.1, 2.52.6): both load

  A successful load also means JNI_OnLoad found and loaded the system WebKitGTK.

• Not tested locally: the arm64 leg. It's the same step, the debian:11 image is multi-arch, and the archive has arm64 libwebkit2gtk-4.0-dev 2.44.2. CI will be the first run.

Follow-ups (not in this PR)

• Consumers need a new swingwebview release, then a matching webview-run release, before agentic-app-framework picks this up (the two versions must move together).
• The jdeploy arm64 Linux launcher needs glibc 2.34, so arm64 on Ubuntu 20.04 still won't launch. That's a separate client4jgo fix.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KJGbJfSqGDbZWCbUnoKYVx

---

Generated by Claude Code