Repository navigation
ghc ladder (x86_64): take only the glibc-bedrock-2.42 sysroot slice, through runtime_deps - #939
bryan-minimal wants to merge 2 commits into
Conversation
…d time
Same hazard pkgs#937 fixes for the JVM ladder. glibc-bedrock-2.42 is
prebuilt, and a prebuilt lands its whole tarball, which ignores the
output globs. That tarball holds a complete glibc 2.42 at /usr/lib
besides the versioned sysroot. When two deps ship the same path, the
sandbox keeps the one whose spec hash sorts lowest. Production glibc
(15dae0..) currently sorts below glibc-bedrock-2.42 (3ae053..), so the
rungs build. A glibc rehash that sorts above it would put libc 2.42 at
/usr/lib and break every production tool in the build (GLIBC_2.43 not
found).
microhs-0.16, ghc-4.08.2 through ghc-9.6.7, and ghc's amd64 boot now
take subsetOf glibc-bedrock ["sysroot_lib", "sysroot_include"] as the
build dep. The build scripts only use /usr/lib/glibc-bedrock-2.42/
{lib,include}. Runtime deps already took the sysroot_lib slice. The
arm64 spec hashes do not change.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… a build-dep subsetOf A subsetOf in build_deps panics the builder. SpecBuild::build_deps_mapped (minimal crates/op/src/specs.rs) skips only BuildDep::Build and hits todo!() on BuildDep::Subset. This is the panic pkgs#937 got on build-bot (run aa4add24, "not yet implemented: input: Subset(...)"). A spec's own runtime_deps are mounted in its build sandbox (Transitives::new starts from them). So each rung now drops glibc-bedrock from build_deps and takes subsetOf glibc-bedrock ["sysroot_lib", "sysroot_include"] in runtime_deps: - microhs-0.16 through ghc-7.0.4 widen their existing sysroot_lib slice. - ghc-7.6.3 through ghc-9.6.7 had no runtime_deps; they gain the slice (x86_64 only). - ghc gets the slice through its ghc-9.6.7 boot. No ladder package keeps a bare glibc-bedrock-2.42 anywhere in its closure. A bare reference would widen the slice back to the whole tarball, because Transitives::upsert unions to the full build. The arm64 spec hashes are unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
Comment |
There was a problem hiding this comment.
The change looks right, but there's no completed build. The only check, minimal build, was cancelled after 1.5 min, and the PR body says "Untested until this build". The base is #774's branch, so minimal-check, closure, reports and CodeRabbit didn't run either. Please get a full build on both arches before this goes into #774.
On the code:
- No second glibc reaches users. Each rung pulls the previous one only via
build_deps, andpackages/ghc/build.ncl'sruntime_depsare unchanged. The slice lives at the versioned path, and the rung binaries really do use$SR(loader and rpath), soruntime_depsis the honest place for it. - arm64 is unchanged, with
runtime_deps = []from 7.6.3 up, consistent with yourmip dump --arch arm64diff. - libm and gconv are covered by the existing fixlib
libm.sorewrite andGCONV_PATH=$SR/lib/gconv, both of which sit inside the slice. - The slice holds only 9 relative same-directory
.sosymlinks, so subset copying should be fine. #941's green build is partial evidence of that.
Once #940 lands and reaches #774's branch, bare imports of the bedrock become safe, so this is defence in depth rather than a fix. It's worth deciding whether its full amd64 GHC-ladder rebuild is worth it, or whether to fold it into #774 instead of landing it separately.
Generated by Claude Code
|
Closing in favour of #941's shape. #941 (merged) added the 🤖 Generated with Claude Code |
…ollection
On amd64 the whole glibc-bedrock-2.42 brings its plain /usr tree, a full glibc 2.42 that collides
with production glibc 2.44 path for path; whichever lands first wins (pkgs#895's GLIBC_2.43
failure). The rungs now import glibc-bedrock-2.42-sysroot, which carries only
usr/lib/glibc-bedrock-2.42/{lib,include}: in cc_build in place of the bare bedrock, in cc_runtime in
place of the sysroot_lib subset, and in ghc's amd64 boot list. arm64 spec hashes are unchanged
(the rungs never import the bedrock there); amd64 rebuilds 15 of the 16 GHC-ladder specs.
Replaces #939.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Stacked on #774 (base
bryan/ghc-ladder-clean-20260928). The GHC ladder is not on main yet. Do not merge before #774. This can also be folded into #774.What
On x86_64, no GHC-ladder package depends on the whole
glibc-bedrock-2.42any more. Each one takes only the sysroot slice, throughruntime_deps:microhs-0.16throughghc-7.0.4:glibc-bedrockis gone frombuild_deps. Their existingruntime_depsslice["sysroot_lib"]gainssysroot_include.ghc-7.6.38000 throughghc-9.6.7:glibc-bedrockis gone frombuild_deps. These rungs had noruntime_deps; they now have the slice, on x86_64 only.ghc: the bareglibc-bedrockis gone from the amd64 boot list. The slice now comes throughghc-9.6.7'sruntime_deps.Why runtime_deps and not
subsetOfin build_deps (the #937 shape)A
subsetOfinbuild_depscrashes the builder.SpecBuild::build_deps_mapped(minimalcrates/op/src/specs.rs) skipsBuildDep::Buildand sends every other variant totodo!("input: {:?}"). #937 failed this way on build-bot (run aa4add24):A spec's own
runtime_depsare mounted in its build sandbox, becauseTransitives::newstarts from them. So the slice reaches the build without that code path.The slice must be the only reference.
Transitives::upsertturns a subset into the full build as soon as any bare reference to the same package appears in the closure. That is why every bare import is removed, not just most of them. I checkedmip dump: no ladder package keeps a bareglibc-bedrock-2.42dependency, and no package anywhere has one inruntime_deps.Why
glibc-bedrock-2.42isprebuilt = true, and a prebuilt lands its whole tarball, ignoring its output globs. The tarball holds a complete glibc 2.42 at/usr/lib(libc.so.6,libm.so.6, the loader, headers) besides/usr/lib/glibc-bedrock-2.42/. When two deps ship the same path, the sandbox keeps the one whose spec hash sorts lowest.On #774's head, production
glibchashes to15dae0…and the prebuiltglibcto296c15…. Both sort belowglibc-bedrock-2.42at3ae053…, so production glibc wins/usr/libtoday. That is hash luck. When a glibc rehash sorts above3ae053…(about 77% odds per rehash), libc 2.42 takes/usr/lib, and every production tool in a rung's build (make, bash, patch, binutils 2.47) fails withGLIBC_2.43 not found. That is the classpath-0.93 failure on #895.The rung scripts only use
/usr/lib/glibc-bedrock-2.42/{lib,include}:$SR/lib,$SR/include, andGCONV_PATH=$SR/lib/gconv. Both are inside the slice.The 10-16 microhs failure (build 2210effb) is a different bug, already fixed
That build ran at 17b6cac. The sysroot's
libm.solinker script names/usr/lib/libm.so.6, which in the sandbox is production libm 2.44. So-lmrecorded 2.43+ symbol versions, and at run time the wrapper's-rpath $SR/lib:/usr/libloaded the 2.42 libm. 76a95be fixed it five minutes later by regeneratinglibm.sointofixlib. #774 then built green on both arches at 17bee18 (run f8c7e787, 10-17), every rung included.Blast radius
mip dump --packages --arch arm64before and after: 596 packages, all identical.nickel format --checkis clean.Untested until this build
No package has used a runtime
subsetOfof a prebuilt in a real sandbox yet. Every existing consumer also had a bare import, which widened the slice back to the whole tarball.SubsetBuildcopies the matched files withstd::fs::copy. If the sysroot'slib/contains a symlink that copy cannot follow, this build is where it will show up.🤖 Generated with Claude Code