Repository navigation
jvm ladder: take only the glibc-bedrock-2.42 sysroot, not its whole tarball - #937
bryan-minimal wants to merge 1 commit into
Conversation
…arball The sealed glibc-bedrock-2.42 artifact (#825) is a prebuilt, and a prebuilt lands in the sandbox as its whole extracted tarball: its `outputs` globs are not applied. That tarball carries a complete glibc 2.42 at /usr/lib (libc.so.6, ld-linux-x86-64.so.2, libm.so.6, ...) and /usr/include, next to the sysroot at /usr/lib/glibc-bedrock-2.42. The production glibc 2.44 ships the same paths. The sandbox assembles the root first-writer-wins in spec-hash order, so the winner at /usr/lib/libc.so.6 depends on which hash sorts lower. At #775 production glibc's hash (15dae0..) sorted ahead of glibc-bedrock's (3ae053..), so it won. #895 (a python patch) changes glibc's hash, because python is a build dep of glibc, to b8676f.., which sorts after. The 2.42 libc then took /usr/lib, and every production tool in classpath-0.93's sandbox that needs GLIBC_2.43 failed: sort: /usr/lib/libc.so.6: version `GLIBC_2.43' not found (required by sort) jikes-1.22 hit the same error during config.status, but there it was not fatal. A subset dep does apply the output globs. All 28 JVM rungs now take subsetOf glibc-bedrock-2.42 ["sysroot_lib", "sysroot_include"]. Their build.sh files only ever read ${SR}/lib and ${SR}/include. The same subset is used for build and runtime deps. gcc-15.2.0-glibc already takes the sysroot this way. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to
|
| Check name | Status | Explanation |
|---|---|---|
| Description Check |  |
Check skipped - CodeRabbit’s high-level summary is enabled. |
| Title check | |
The title clearly and concisely describes the main change: restricting JVM dependencies to the glibc-bedrock 2.42 sysroot instead of the full tarball. |
| Docstring Coverage | |
No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0… |
| Linked Issues check | |
Check skipped because no linked issues were found for this pull request. |
| Out of Scope Changes check | |
Check skipped because no linked issues were found for this pull request. |
Full details: Docstring Coverage
-
Explanation
No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (28 skipped: 28 unsupported.)
✨ Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Commit to this branch
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Comment @coderabbitai help to get the list of available commands.
|
Closing in favour of #940. This approach can't build: minimal doesn't support #940 fixes the same collision at the source. It repacks the sealed glibc-bedrock-2.42 prebuilt to contain only |
classpath-0.93 failed on pkgs#895 (a python-only change) with
`sort: /usr/lib/libc.so.6: version GLIBC_2.43 not found`. The rungs
depend on the whole glibc-bedrock-2.42, and its sealed amd64 tarball
carries a full glibc 2.42 at /usr/lib (listed: usr/lib/libc.so.6,
ld-linux-x86-64.so.2, 4087 entries), whatever its output globs say. That
collides with production glibc 2.44 path for path (~1400 files); the
sandbox keeps whichever lands first ("Not linking ... already exists"),
which shifts with fetch timing, so an unrelated python change flipped
classpath's /usr/lib/libc.so.6 to 2.42 and every production tool in the
sandbox stopped loading.
The new glibc-bedrock-2.42-sysroot collection carries only
usr/lib/glibc-bedrock-2.42/{lib,include}, all the rungs use (SR=), and
the 28 rungs import it in place of glibc-bedrock-2.42. A collection
because `subsetOf` is only supported in runtime_deps: in build_deps it
panics minimal's executor (op/src/specs.rs:88, todo!), which is what
stopped #937.
Verified on the lab (amd64, mip): main + #895's python + this builds
jikes-1.22 and classpath-0.93 (rc=0), with no glibc path conflict in
classpath's sandbox; without it, the same tree reproduces the failure.
Rebuilds the amd64 JVM ladder once.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
What broke
#895 (python gh-157579 backport) failed in the merge queue at
ae38bb63, on amd64. Main is still green.That is build-bot run
a4ad3a81, file93.jsonl. jikes-1.22 hit the samesorterror in27.jsonlduring config.status, but there it was not fatal.Root cause
glibc-bedrock-2.42artifact from amd64: consume the bootstrap chain as sealed tarballs, like arm64 (interim; stops ladder rebuilds) #825 (sha256/d0850b65…) is the rung's rawOUTPUT_DIR. Besides the sysroot at/usr/lib/glibc-bedrock-2.42, it ships a complete glibc 2.42 at/usr/lib(libc.so.6,ld-linux-x86-64.so.2,libm.so.6, …) and at/usr/include.prebuilt = truepackage is extracted whole into the sandbox, and itsoutputsglobs are not applied (minimalcrates/op/src/specs.rs,materialize_prebuilt). AsubsetOfdep does apply them (SubsetBuild).BTreeSet<SandboxMapped>sorted by cache path<hash[0..2]>/<hash[2..]>(crates/sandbox/src/config.rs). A collision only produces awarn!.glibchashed15dae0…andglibc-bedrock-2.42hashed3ae053…, so production glibc won. python: backport gh-157579 (CVE-2026-12345, tempfile cleanup race) to 3.14.8 #895 changes glibc's hash tob8676f…(python is a build dep of glibc), which sorts after3ae053…. The 2.42 libc then took/usr/lib, and every production tool built against 2.44 (sortfrom coreutils) fails to load. Hashes are fromMINIMAL_SCIENCE_MODE=1 mip dump --packages --arch amd64atc67b1aa5and atae38bb63.The bug was latent from #775 on. Any change to production glibc's hash flips it with probability of roughly 3/4: python, openssl, glibc itself, or anything else in glibc's build closure.
Fix
All 28 JVM rungs (jikes-1.22, classpath-0.93/0.99/devel, jamvm-1.5.1/2.0.0, ant-bootstrap, ecj-bootstrap, ecj4-bootstrap, icedtea-7/8, openjdk-9..25) now take
instead of the whole package, for both build and runtime deps. Their
build.shfiles only ever read${SR}/liband${SR}/include.gcc-15.2.0-glibcalready takes the sysroot this way. After this change,mip dumpon amd64 shows no package depending on the wholeglibc-bedrock-2.42. It evaluates cleanly on arm64 too, where the rungs are empty arms.The whole ladder rehashes, so this PR rebuilds all 28 rungs.
Testing notes
15dae0…and wins anyway. A green build here proves the rungs build on the subset, but it does not reproduce the collision. python: backport gh-157579 (CVE-2026-12345, tempfile cleanup race) to 3.14.8 #895 rebased onto this is the real test.glibc-bedrock-2.42bare reintroduces this hash lottery. The same applies to the from-source spec'susr/include/**/usr/bin/**outputs whenhex0/amd64-ladder.nclis enabled.🤖 Generated with Claude Code
Summary by CodeRabbit