mi/werkator
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

Correct the runtime bundle's glibc rule: the JDK vendor sets the floor

Browse Source 
ADR 0006 assumed the bundle inherits the build machine's glibc, which would
have blocked the Hostsharing Managed Webspace (glibc 2.36, dev machine 2.39).
Measuring all 33 ELF files of the produced bundle shows GLIBC_2.15 as the
highest required symbol version: jlink copies Temurin's prebuilt binaries
instead of compiling, so the floor is the JDK vendor's build environment and
the build machine's glibc is irrelevant unless the toolchain resolves to a
distribution-packaged JDK.

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
mhoennig
2026-08-11 10:23:15 +02:00
co-authored by Claude
parent c77de1c725
commit 903a87e547
2 changed files with 9 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/adrs/0006-2026-08-10.runtime-bundle-distribution.md
+5 -1
View File
@@ -36,7 +36,11 @@ Bad:
- A directory tree, not a single file (still one tarball to copy).
- JVM startup (~1-2 s) instead of native-image startup — irrelevant for a long-running server.
- The jlink image links glibc dynamically: build on glibc ≤ target (Ubuntu 24.04 dev machine: 2.39; vm4006 Debian 13: 2.41 — compatible), same architecture.
- The jlink image links glibc dynamically, so it is bound to an architecture and a minimum glibc.
Corrected on 2026-08-11: that minimum is **not** the build machine's glibc, as originally assumed here.
`jlink` compiles nothing — it copies the JDK vendor's prebuilt binaries out of the jmods, so the floor is the vendor's build environment.
Measured over all 33 ELF files of the bundle produced by the Temurin 21 toolchain, the highest required symbol version is `GLIBC_2.15`, which every supported distribution exceeds.
The build machine's glibc only matters if the toolchain resolves to a distribution-packaged JDK instead of Temurin.
### GraalVM Native Image