validation: post-split cabal re-pin + stage-qualified host-only (DO NOT MERGE — pins WIP cabal#378)#189
Draft
angerman wants to merge 14 commits into
Draft
validation: post-split cabal re-pin + stage-qualified host-only (DO NOT MERGE — pins WIP cabal#378)#189angerman wants to merge 14 commits into
angerman wants to merge 14 commits into
Conversation
The hosted Windows runner's make changed from MSYS2 (MAKE_HOST=x86_64-pc-msys) to Cygwin (x86_64-pc-cygwin). Both `ifeq ($(MAKE_HOST),x86_64-pc-msys)` guards then fell through, dropping the Windows CC/CXX/LD overrides so CC/CXX defaulted to cc/g++ and ghc-toolchain failed stage1 settings generation with "g++ not found". Match all Windows make-host triples (msys, cygwin, mingw32) via $(filter ...).
release.yml was broken at the root by the Cabal source-repo pin
`tag: stable-haskell/master`, which cabal could not resolve at stage0 (every
platform died building cabal-install). Pin an explicit, resolvable SHA on the
feature/wasm-cross-ghcup-stack branch (aa57a49) which carries the fixes the
build needs:
* host-only `package *` handling, so cabal.project.stage2.dynamic's
`shared: True` no longer builds the build-stage packages shared (those
failed to link against the bootstrap GHC on ~every platform:
"ld: cannot find -lHSbytestring-...-ghc9.8.4");
* #361 target-prefix-aware companion-tool guess (cross ghc-pkg);
* a self ($ORIGIN/@loader_path) rpath entry so an instantiated Backpack
unit finds its signature implementation under musl (testsuite T14304 on
Alpine; glibc masked it via the runtime LD_LIBRARY_PATH GHC sets before
dlopen, which musl ignores).
Adapt the tree to this Cabal:
* cabal.project.stage0: drop the `hooks-exe` subdir (absent on this branch);
* compiler/Setup.hs, libraries/ghc-boot/Setup.hs: revert the Cabal-3.17
Verbosity/VerbosityHandles-split adaptation (this branch predates it);
* cabal.project.stage{1,2.common}: compile out libffi's deprecated (Java)
raw API with -optc-DFFI_NO_RAW_API=1, which RockyLinux 8 gcc treats as a
hard error (GHC does not use that API).
The FreeBSD self-hosted runner has no JS toolchain (llc/opt/emscripten), so it cannot build the javascript-unknown-ghcjs cross target. Drop both the JS bindist and haskell-toolchain.tar.gz (which depends on stage3-javascript-unknown-ghcjs) from the FreeBSD build; ship only the native ghc/cabal/tests bindists.
Replace the pre-split aa57a49 pin (feature/wasm-cross-ghcup-stack) with
feat/wasm-cross-ghcup-stack-next (ee3b55e6): stable-haskell/cabal's
wip/andrea/stage-qualified-options (#378, Host-only `package *` handling)
+ target-prefixed ghc-pkg guess (#361) + absolute-rpath relativization
(#368) + the $ORIGIN/@loader_path self-rpath (#385, musl T14304).
Being post-split, the next branch carries the Cabal-3.17 VerbosityHandles
API and the hooks-exe sub-dir, so two adaptations the aa57a49 pin forced
are no longer needed and are reverted here:
* compiler/Setup.hs, libraries/ghc-boot/Setup.hs: restore the upstream
`#if MIN_VERSION_Cabal(3,17,0)` VerbosityHandles form (un-revert).
* cabal.project.stage0: restore the hooks-exe sub-dir.
The libffi-clib FFI_NO_RAW_API workaround (Rocky gcc-8) is unrelated to
the pin and is kept. Tracked by stable-haskell/cabal#384; re-pin to
`master` once #378 lands there.
The post-split Cabal (#378, `package <stage>:*`) does not treat an unqualified
`package *` as host-only the way the pre-split aa57a49 pin did, so a bare
`package * { shared: True }` here also built the BUILD-stage tools shared and
they failed to link the bootstrap GHC's static-only libs
("ld: library not found for -lHSbytestring-...-ghc9.8.4", on build:os-string).
Split it per #378's own fixture: `package host:*` carries shared/dynamic,
`package build:*` forces the build tools static. Validated locally:
stage0+stage1+stage2 (DYNAMIC=1) build green on aarch64-darwin and stage2 ghc
is dynamically linked (@rpath/libHSghc-9.14-ghc9.14.dylib).
…ll guard Two of the fixes #181 (feat/wasm-cross-ghcup) carries but the stable-ghc-9.14 / #188 base lacks, needed to build stage3-wasm32-unknown-wasi: * cabal.project.stage3: replace the stale `if os(wasi) { package * shared:True }` (which alone leaves GHC's wasm link pipeline inconsistent — fails at the ghc-internal link with [GHC-74335]) with #181's `if arch(wasm32)` triple (shared + executable-dynamic + rts +dynamic). * rts/RtsStartup.c: guard the promoteBootLibrariesToGlobal() *call site* with !defined(wasm32_HOST_ARCH) to match its definition (which is already wasm-excluded; it uses dladdr/dlopen). Without this the wasm rts fails to compile ("call to undeclared function 'promoteBootLibrariesToGlobal'"). NOTE: these are necessary but NOT sufficient. stage3-wasm still fails at the ghc-internal shared-lib link ([GHC-74335] "-dynamic ignored when linking binaries on WASM" -> mismatched interface profile tag) because the real fix is in the GHC COMPILER, on #181 but not here: - 4d84ace "compiler: per-target settings drive GHC Dynamic / Profiled" (Platform/Settings/Settings.IO/Driver.Session: targetIsDynamic etc.) - 7396909 "rts+compiler: wasm32 cross-target patches" (esp. compiler/GHC/Linker/Dynamic.hs — the wasm dynamic-link handling) Porting those is the #181 <-> stable-ghc-9.14 wasm integration, tracked separately. (7396909 also rewrites compiler/Setup.hs + ghc-boot/Setup.hs, which conflicts with the modern-pin VerbosityHandles restore here.)
Ports the two GHC-source commits #181 (feat/wasm-cross-ghcup) carries but the stable-ghc-9.14 / #188 base lacks, which are the real fix for the stage3-wasm ghc-internal link failure ([GHC-74335] "-dynamic ignored when linking binaries on WASM" -> mismatched interface profile tag): - 7396909 "rts+compiler: wasm32 cross-target patches" (GHC/Linker/Dynamic.hs wasm dynamic-link handling, Driver/Session.hs, Runtime/Interpreter/Wasm.hs, rts/linker/elf_got.c, rts/RtsStartup.c) - 4d84ace "compiler: per-target settings drive GHC Dynamic / Profiled" (Platform/Settings/Settings.IO/Driver.Session: platformMisc_targetIsDynamic et al., defaulting True so the wasm target is dynamic-capable) compiler/Setup.hs + libraries/ghc-boot/Setup.hs were KEPT at the modern-pin VerbosityHandles form (7396's pre-split Setup.hs revert was discarded — it's incompatible with the post-split cabal pin).
… pin happy/alex/hpc) stage1 had no `active-repositories: :none` and no build-tool pin (stage2/stage3 do). So happy/alex floated to Hackage's newest; once happy-2.1.7 was published stage1 built happy-lib-2.1.7, which broke the build (genprimopcode GHC-44432 / `happyDoParse` vs the pinned 2.1.5 happy template). Latent until happy-2.1.7's release — which is why CI that was green before now fails across platforms. Add `:none` + explicit alex-3.5.2.0 / happy-2.1.5 / happy-lib-2.1.5 URLs, and hpc-0.7.0.2 (a dep of ghc; the bootstrap's installed hpc wants the old directory, conflicting with the pinned directory-1.3.10.0). Versions match stage2/stage3. Resolve verified: stage1 now plans happy-2.1.5, not 2.1.7.
…ings stack" This reverts commit d89d51e.
… wasm call guard" This reverts commit 17bdcd1.
T4437 checks that GHC's language extensions (xFlags) are all known to
Cabal's `KnownExtension` enum — any GHC extension Cabal doesn't know is
reported as a "GHC-only" flag, and the golden T4437.stdout captures the
currently-accepted set of such discrepancies.
The committed golden listed two GHC-only extensions:
ExplicitLevelImports
ImplicitStagePersistence
Those were GHC-only against the *older* boot Cabal-syntax. The modern
cabal re-pin (source-repository-package Cabal/Cabal-syntax ee3b55e6,
based on 3.17.0.1) adds BOTH extensions to `KnownExtension`, so GHC's
extension set is now a subset of Cabal's: the GHC-only set is empty and
T4437 emits no output.
This is an improvement — Cabal caught up with GHC — not a regression:
the actual run now prints nothing, so the golden must be empty to match.
With this, all four nix-ci testsuite jobs (x86_64-linux / aarch64-darwin
x dynamic=0/1) are green; T4437 was the sole residual after the
per-target-settings revert that fixed the dyn-library test failures.
…ver)
The Windows release build failed in stage1 with a solver conflict:
[__0] trying: host:Cabal == Cabal-3.17.0.1 (user goal)
[__1] trying: host:time == installed:time-1.12.2 (dependency of host:Cabal)
[__2] rejecting: host:Win32 == source:Win32-2.14.2.1
(conflict: host:time => host:Win32==installed:Win32-2.13.4.0)
[__2] fail (backjumping, conflict set: host:Win32, host:time)
The post-split host Cabal (3.17.0.1) depends on `time`. With nothing
pinning it, the solver reuses the bootstrap's *installed* time-1.12.2,
which is bound to the bootstrap's *installed* Win32-2.13.4.0 — conflicting
with our pinned Win32-2.14.2.1 (needed by the modern boot libs).
Fix: pin time-1.15 (the GHC 9.14 boot version) as a source package and
force it via `time source`, so it rebuilds against Win32-2.14.2.1. This
mirrors stage3, which already pins time-1.15 as source. Non-Windows stages
are unaffected in outcome (time has no Win32 dep there); they just build
time from source like the other boot libs, which is the more correct state
anyway (the installed time-1.12.2 was a bootstrap-version skew).
The rockylinux and Mac x86_64 JS-cross builds failed archiving the
build-stage happy-lib grammar lib:
/usr/bin/ar: invalid option -- 'L'
Error: [Cabal-7125] Failed to build lib:grammar from
build:happy-lib-2.1.5-grammar
make: *** [Makefile:1038: stage3-javascript-unknown-ghcjs] Error 1
`emsdk_env.sh` was sourced before the *entire* `make`, so emsdk's LLVM
toolchain was on PATH while ghc-toolchain detected the HOST toolchain.
The resulting host settings recorded an llvm-ar-style `ar supports -L:
YES`, but build-stage archives were then created with the system GNU ar,
which rejects the `L` modifier. (The native nix-ci build has no emsdk and
is green, confirming the system ar is correct for the host.)
Fix: build the HOST bindists (ghc/cabal/tests) before sourcing emsdk, then
source emsdk and build only the JS cross targets (haskell-toolchain +
ghc-javascript), which reuse the already-built host stage2 and its
emsdk-free settings. Non-emsdk platforms are unchanged.
The previous commit pinned time-1.15, which broke the native build on ALL
platforms (nix-ci run 27612378098: 4/4 jobs failed at the stage1 solve):
[__1] next goal: host:time (user goal)
[__1] rejecting: host:time == host:source:time-1.15
(conflict: host:hpc => host:time>=1.2 && <1.15)
[__1] rejecting: host:time == host:installed:time-1.12.2-inplace
(constraint from user target requires ==1.15)
[__1] fail (backjumping, conflict set: host:hpc, host:time)
RCA: stage1 already pins hpc-0.7.0.2 (a dep of `ghc`, needed so it builds
against the pinned directory-1.3.10.0 rather than the bootstrap hpc's old
directory). hpc-0.7.0.2 constrains `time >=1.2 && <1.15`, so time-1.15 is
out of range. stage3 gets away with time-1.15 only because hpc is not in
its active dependency closure there, so the bound never activates.
The Windows fix never required a *newer* time -- only a *source* time, so
`allow-newer: Win32:*` lets it accept the pinned Win32-2.14.2.1 instead of
dragging in installed Win32-2.13.4.0 via installed time. time-1.14 is the
newest release satisfying hpc's <1.15 bound (1.13 is deprecated on Hackage)
and still builds from source against Win32-2.14.2.1. The `time source`
constraint is retained.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Validation only — DO NOT MERGE. This pins the WIP cabal branch
feat/wasm-cross-ghcup-stack-next(stable-haskell/cabal #378 host-only +#361 + #368 + #385
$ORIGIN), to validate the eventual post-split re-pinacross the full release matrix. It cannot merge until cabal #378 lands.
Replaces the pre-split
aa57a49pin and drops both pre-split hacks:compiler/Setup.hs+ghc-boot/Setup.hsrestored to the upstream#if MIN_VERSION_Cabal(3,17,0)VerbosityHandlesform.cabal.project.stage0hooks-exesub-dir restored.Plus the one adaptation the post-split host-only model needs:
cabal.project.stage2.dynamicstage-qualifies
shared/executable-dynamictohost:*(withbuild:*forcedstatic), because an unqualified
package *no longer scopes host-only on #378.Validated locally on aarch64-darwin: stage0 + stage1 + stage2 (DYNAMIC=1)
green, stage2 ghc dynamically linked. This run exercises the breadth
(DYNAMIC=0, Linux/Windows/FreeBSD/musl, cross). See stable-haskell/cabal#384.