Skip to content

ci: fix release.yml — Cabal pin + Windows/RockyLinux/FreeBSD platform builds#188

Open
angerman wants to merge 3 commits into
stable-ghc-9.14from
fix/release-platform-toolchain
Open

ci: fix release.yml — Cabal pin + Windows/RockyLinux/FreeBSD platform builds#188
angerman wants to merge 3 commits into
stable-ghc-9.14from
fix/release-platform-toolchain

Conversation

@angerman

@angerman angerman commented Jun 12, 2026 •
edited
Loading

Copy link
Copy Markdown

Unblocks and fixes the Build and release (release.yml) pipeline, which has
been red on stable-ghc-9.14 every night. Surfaced while validating #181.
Four commits, each a distinct root cause:

0. Cabal pin no longer resolves → masks everything (commit 4)

The Cabal source-repo pinned the bare branch stable-haskell/master, which
stock cabal-3.14.2.0 fails to resolve in its shallow git fetch at stage0
("fatal: Failed to resolve stable-haskell/master as a valid revision",
Makefile:560). Every platform aborts here before any build step — the real
first failure behind the daily-red nightly. Now SHA-pinned to the current
stable-haskell/master tip (843fceb) across all four stage project files
(base already carries the ghc-boot/Setup.hs Verbosity adaptation, so it's
API-compatible).

1. Windows — make-host guard (commit 1)

Hosted Windows runner's make switched MSYS2→Cygwin (MAKE_HOST now
x86_64-pc-cygwin); both ifeq ($(MAKE_HOST),x86_64-pc-msys) guards missed,
dropping the Windows CC/CXX/LD overrides → g++ not found in stage1 settings
gen. Now matches msys/cygwin/mingw32 via $(filter …).

2. RockyLinux 8 — libffi-clib -Werror (commit 2)

Rocky-8 gcc makes libffi-clib's deprecated-declaration a hard error in stage1.
Adds -optc-Wno-error for libffi-clib in cabal.project.stage1 (mirrors
stage2.common; no -no-rts — stage1 uses the stock bootstrap GHC).

3. FreeBSD — JS cross target (commit 3)

FreeBSD self-hosted runner has no JS toolchain; it built ghc-javascript-…
unconditionally and failed at stage3-javascript-unknown-ghcjs. Now ships only
the native FreeBSD bindist.

The Alpine T14304 failure (backpack dynamic linking under musl) is a
separate testsuite issue, investigated independently — not in this PR.

Verified by release.yml + base CI on this PR.

@angerman angerman changed the title ci: fix release.yml Windows / RockyLinux / FreeBSD platform builds ci: fix release.yml — Cabal pin + Windows/RockyLinux/FreeBSD platform builds Jun 12, 2026
angerman added 3 commits June 15, 2026 06:43
@angerman
ci(release): detect cygwin/mingw make-hosts, not just msys
8146d56 
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 ...).
@angerman
build: pin Cabal to stable-haskell/cabal aa57a49 and adapt the build
964708b 
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).
@angerman
ci(release/freebsd): build the native bindist only (no JS cross)
a8a9d3e 
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.
@angerman angerman force-pushed the fix/release-platform-toolchain branch from f955af7 to a8a9d3e Compare June 15, 2026 00:41
@angerman angerman mentioned this pull request Jun 15, 2026
Open
7 tasks
angerman added a commit that referenced this pull request Jun 15, 2026
@angerman
wasm-cross (partial): arch(wasm32) shared-triple + RtsStartup wasm ca…
17bdcd1 
…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.)
angerman added a commit that referenced this pull request Jun 15, 2026
@angerman
compiler+rts: port #181 wasm32 cross-target + per-target-settings stack
d89d51e 
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).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@angerman