feat: add Haskell build toolchain (GHC, Cabal, Stack) - #178

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Looked at the hard-link error — turns out it's not a problem with your PR, but with how the orchestration extracts tarballs when extract = true is combined with strip_prefix. There's a workaround that lets your PR land without waiting on an orchestration fix.

Why the build fails

GHC 9.10.1's source tarball uses tar hardlink entries to share NofibUtils.hs across ~20 sibling directories under nofib/real/:

$ curl -sL https://downloads.haskell.org/~ghc/9.10.1/ghc-9.10.1-src.tar.xz | tar -tJv | grep nofib/real/.*NofibUtils.hs
-rw-rw-rw- ghc/ghc 1926 ghc-9.10.1/nofib/real/compress2/NofibUtils.hs
hrw-rw-rw- ghc/ghc    0 ghc-9.10.1/nofib/real/fulsom/NofibUtils.hs link to ghc-9.10.1/nofib/real/compress2/NofibUtils.hs
hrw-rw-rw- ghc/ghc    0 ghc-9.10.1/nofib/real/compress/NofibUtils.hs link to ghc-9.10.1/nofib/real/compress2/NofibUtils.hs
... (18 more)

The link target stored in each hardlink entry is the un-stripped path (ghc-9.10.1/nofib/real/compress2/NofibUtils.hs). The orchestration's extract_tar_impl strips ghc-9.10.1/ from the destination path but doesn't strip it from the hardlink target, so when it tries to hard_link("ghc-9.10.1/nofib/real/compress2/NofibUtils.hs", dest) the source path doesn't exist — the real file was extracted to dest/nofib/real/compress2/NofibUtils.hs (stripped).

Workaround: do the extraction in build.sh (matches glibc / linux_headers / binutils / gcc)

Most low-level toolchain packages already sidestep this by taking delivery of the raw .tar.xz and running tar xJf inside build.sh. For example packages/linux_headers/build.ncl:

{
  url = "gs://minimal-staging-archives/linux-%{version}.tar.xz",
  sha256 = "..."
  # no extract = true, no strip_prefix
} | Source,

And the build.sh for those packages opens with tar xJf linux-${version}.tar.xz && cd linux-${version}.

For your PR, the change is roughly:

packages/ghc/build.ncl — drop extract = true and strip_prefix:

{
  url = "https://downloads.haskell.org/~ghc/%{version}/ghc-%{version}-src.tar.xz",
  sha256 = "bf386a302d4ee054791ffd51748900f15d71760fd199157922d120cc1f89e2f7",
} | Source,

packages/ghc/build.sh — extract first:

#!/bin/sh
set -ex

tar xJf ghc-${version}-src.tar.xz
cd ghc-${version}

./boot
./configure ...

(You'll need to thread version into build.sh via build_args — build_args = { include version } in build.ncl makes it available as ${version} in the script, which your PR already does.)

This pattern is what glibc, linux_headers, binutils, and gcc all use — it uses the real tar binary inside the sandbox, which handles hardlinks correctly.

Optional: keep extract = true for the prebuilt fallbacks

The two replace_on_cycle prebuilt tarballs (ghc-9.10.1-x86_64-deb12-linux.tar.xz and -aarch64-deb11-linux.tar.xz) are produced by make install and shouldn't have hardlink entries — those can keep extract = true. Only the source tarball needs the workaround.

I've also filed an internal followup to fix extract_tar_impl so future packages won't trip on this, but it's not blocking your PR.

Good progress — the extract-in-build.sh refactor is working, the strip-prefix error is behind us. The new error is unrelated and easy to fix.

The bug

./build.sh: line 13: ./boot: No such file or directory

./boot is GHC's developer-side script that regenerates the configure script from configure.ac (it's a Cabal+Python pre-build step that lives in the git repo, not in the source release). Released source tarballs ship configure already generated — running ./boot is unnecessary and impossible since the script isn't packaged:

$ curl -sL https://downloads.haskell.org/~ghc/9.10.1/ghc-9.10.1-src.tar.xz \
    | tar -tJf - | grep -E 'ghc-9.10.1/(boot|configure|configure\.ac)$'
ghc-9.10.1/configure.ac
ghc-9.10.1/configure        ← already generated, this is what you call directly
                            ← (no boot in the tarball)

Fix

Drop the ./boot step entirely. build.sh should jump straight from cd ghc-${version} to ./configure:

 cd ghc-$MINIMAL_ARG_VERSION

 # Remove nofib benchmark suite before any build steps
 rm -rf nofib

-# Generate configure script
-./boot
-
 # Configure GHC
 ./configure --prefix=/usr \
             --disable-split-objs \
             --enable-shared \
             --disable-tests \

Heads-up on a separate sharp edge

The ./configure line ends with --disable-tests \ followed by a blank line. The trailing backslash + blank-line continuation works in most shells, but it's slightly fragile — if set -euo pipefail is interpreted strictly (some sh implementations are picky about empty continuations) you can get a confusing parse error later. Safer to drop the trailing \ so --disable-tests is the final arg cleanly:

 ./configure --prefix=/usr \
             --disable-split-objs \
             --enable-shared \
-            --disable-tests \
+            --disable-tests

Also: set -euo pipefail uses bash-only pipefail. The shebang is #!/bin/sh. If the sandbox's /bin/sh isn't bash, pipefail may not be recognized. Worth either changing the shebang to #!/bin/bash or dropping pipefail (set -eu still gives you fail-on-undef + fail-on-error).

seems like there's a bug that I found somehow, talked with @twitchyliquid64 about it and he was able to repro

All committers have signed the CLA.

Session Summary: GHC Build Fixes (2026-05-21)

Problem

The ghc package was failing on both amd64 and arm64 in CI.

Fixes Applied

1. Install step writing to read-only /usr (amd64 failure)

Commit: 1c5137d

The hadrian install command was writing directly to /usr which is read-only in the sandbox. Added DESTDIR=$OUTPUT_DIR to the install command so files are staged under the output directory.

- _build/bin/hadrian install --prefix=/usr --docs=none
+ DESTDIR=$OUTPUT_DIR _build/bin/hadrian install --prefix=/usr --docs=none

This works because hadrian invokes the bindist Makefile which supports the standard DESTDIR pattern for staging.

2. Missing cabal command (amd64 failure)

Commit: 00e2b76

./configure requires cabal in PATH (AC_PATH_PROG(CABAL,cabal)), but the cabal package depends on ghc, creating a circular dependency. Solved by adding a stub /usr/bin/cabal script (same pattern as the existing sphinx-build stub) to satisfy the existence check. Hadrian's bootstrap.py then downloads and builds the real cabal via internet access.

Also added cabal-install-3.10.3.0 source tarball to build.ncl initially, but reverted after it failed (bootstrap GHC lacks the ~20 Haskell library deps cabal needs).

3. Guideline compliance

Commit: a27a3c3

• Added base to runtime_deps (GHC binaries are dynamically linked against glibc)
• Added needs block declaring dns/internet (hadrian bootstrap downloads cabal)
• Added standalone version test
• Fixed import ordering and formatting

Verification

• All 10 lint checks pass
• Local test build completed successfully in ~52 minutes with zero errors
• arm64 failure (bootstrap GHC binary is x86_64-only) is pre-existing and separate

Summary of Fixes for GHC, Cabal, and Stack Build Failures

I have successfully resolved the build failures for the Haskell toolchain (ghc, cabal, and stack) under GHC 9.10.3 and verified that the entire toolchain compiles, passes static checks, and packages correctly.

Here is a summary of what was changed and why:

1. GHC (packages/ghc/)

• Issue: The Hadrian bootstrap script failed because it could not find hadrian-bootstrap-sources-9.8.1.tar.gz. Additionally, GHC 9.8.2 was being used as the bootstrap compiler, but the offline Hadrian bootstrap sources were designed for GHC 9.8.1, leading to a package database mismatch (cannot find package base-4.19.0.0).
• Fix:
  • Downgraded the GHC bootstrap compiler from 9.8.2 to 9.8.1 in packages/ghc/build.ncl and packages/ghc/build.sh.
  • Added the explicit source dependency for hadrian-bootstrap-sources-9.8.1.tar.gz in packages/ghc/build.ncl to ensure it is fetched and made available in the sandbox.

2. Cabal (packages/cabal/)

• Issue: The Cabal bootstrap process failed because ed25519-0.0.5.0 (at revision 8) had a strict dependency upper bound constraint on ghc-prim (ghc-prim >=0.1 && <0.12). GHC 9.10.3 ships with ghc-prim-0.12.0, violating this constraint.
• Fix:
  • Updated ed25519-0.0.5.0 to revision 9 in packages/cabal/update_bootstrap_json.py. Revision 9 relaxes the upper bound to <1, allowing Cabal to bootstrap cleanly against GHC 9.10.3.

3. Stack (packages/stack/)

• Issue:
  1. Setup.hs failed to compile because GHC 9.10.3's pre-installed Cabal-3.12.1.0 does not export interpretSymbolicPathCWD (which was introduced in Cabal 3.14).
  2. The bundled cabal.config strictly pinned unix == 2.8.6.0, which conflicted with GHC 9.10.3's pre-installed unix-2.8.7.0.
  3. The static checks failed because the captured binary was specified with a wildcard glob (usr/bin/*) instead of being explicitly enumerated.
• Fix:
  • Added a compatibility patch to Setup.hs in packages/stack/build.sh using CPP directives to conditionally import and define interpretSymbolicPathCWD only when compiling with Cabal >= 3.14.0.
  • Relaxed the custom-setup section of stack.cabal to allow compiling Setup.hs with Cabal >= 3.12.
  • Stripped the conflicting unix, Cabal, and Cabal-syntax boot package pins from cabal.config in packages/stack/build.sh.
  • Explicitly listed the captured stack binary output in packages/stack/build.ncl to satisfy the enumerate bins static check.