Haskell GHC 构建问题

[Aleksanaa]

一、主要现状

1. Haskell 包组与版本定义

   • 默认的 haskellPackages 版本定义在：
     https://github.com/NixOS/nixpkgs/blob/79bb2afde2f184c85b2d3c40f140a7a48b78869c/pkgs/top-level/all-packages.nix#L6312-L6350
   • 整体 Haskell 包组的定义在：
     https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/haskell-packages.nix
   • GHC 各版本的 Nixpkgs 定义位置：
     https://github.com/NixOS/nixpkgs/tree/master/pkgs/development/compilers/ghc

2. 交叉编译与工具链讨论

   • RISC-V 上本地编译 GHC 的工具链讨论（与龙芯面临同样问题）：
     native riscv64-linux: error: cannot bootstrap GHC on this platform ('riscv64-linux' with libc 'defaultLibc') NixOS/nixpkgs#231537
   • Nixpkgs Haskell 维护者 sterni 在上游的相关讨论：
     https://gitlab.haskell.org/ghc/ghc/-/issues/22006
   • 上游官方 GHC 交叉编译文档：
     https://gitlab.haskell.org/ghc/ghc/-/wikis/building/cross-compiling
   • 龙芯社区已有成员利用交叉编译构建过 GHC：
     https://bbs.loongarch.org/d/150-ghc-loongarch

3. 相关组件说明

   • GHC：Haskell 的官方编译器
   • native-bignum：替代 GMP 的 Haskell 库
   • hadrian：替代 GNU Make 的构建系统

4. GHC 后端方案

   • LLVM
   • NCG（用 Haskell 编写，目前不支持 LoongArch64）
   • Unregisterised（先编译成 C，再由 C 编译器处理；性能较低，用于 bootstrap）

5. LoongArch64 支持与版本现状

   • GHC 从 9.6 起支持 LoongArch64，配合 LLVM 16 使用（需绕过 LLVM 15 限制并做适当改动，详见链接 1 中注释）。
   • Nixpkgs 中默认 GHC 版本为 9.6.6，在 staging-next 分支中已更新至 9.8.4：
     haskellPackages: Stackage LTS 22 -> 23; ghc: 9.6.6 -> 9.8.4 NixOS/nixpkgs#371032
   • 当前 Nixpkgs 的 Haskell 构建方式：导入官方 bindist tarball，再编译源码（即上游包中的 -binary 流程）。

6. 当前目标
   在 x86_64-linux Hydra 上，构建面向 LoongArch64 的 bindist tarball，并由 Infrastructure Team 上传至 tarball.nixos.org，以与其他受支持架构保持一致的本地构建流程。

---

二、交叉编译问题

1. GHC 的三阶段构建流程

   • Configure 阶段 → Hadrian 构建：
     • stage0、stage1、stage2 三个阶段一次性完成
     • 输入的 Platform Triple 中，build 和 host 都是本地架构，target 是目标架构（即输入 configure 的为 stage0 的 triple）

2. Nixpkgs 中的 Platform Triple 差异

   • pkgsCross.loongarch64-linux.haskell.compilers.ghc984 三元组为 (x86_64, loongarch64, loongarch64)
   • GHC 期望的顺序应为 (build=x86_64, host=x86_64, target=loongarch64)
   • 因此，需要退一步使用：
     • pkgsCross.loongarch64-linux.pkgsBuildHost.haskell.compilers.ghc984
     • 或者 pkgsCross.loongarch64-linux.haskell.packages.ghc984.ghc
       （两者均未完全验证，但准备的 triple 满足 GHC 要求）

3. 绕过libffi编译错误

   • libffi 在 stage0 提前介入，导致编译失败：
     • 阶段使用的 libffi 头文件期望 gcc 定义 __loongarch__，但此时的 gcc 尚未打好宏
     • 原因可能是 configureFlags 中传入的 libffi 来自 targetPlatform
   • 当前对策：使用ghc自带libffi：libffi = null

4. 示例 Derivation 片段
   libffi = null；且暂不开启 LLVM，启用 unregisterised：

   callPackage ../development/compilers/ghc/9.8.4.nix {
     bootPkgs = bb.packages.ghc963Binary;      # 以 GHC 9.6 binary 为 bootPkgs
     inherit (buildPackages.python3Packages) sphinx;
     inherit (buildPackages.darwin) xattr autoSignDarwinBinariesHook;
     buildTargetLlvmPackages = pkgsBuildTarget.llvmPackages_15;
     llvmPackages = pkgs.llvmPackages_15;
     useLLVM = false;
     libffi = null;
     enableUnregisterised = true;
   }

这样在haskell-packages.nix修改ghc 9.8.4理论上就可以开始编译。

5. 在 common-hadrian.nix 中的调整

   • 将默认 finalStage 从 stage1 改为 stage2
   • 判断条件为：

     stdenv.hostPlatform.canExecute stdenv.targetPlatform

     • stage1 通常可完成，能生成在 x86_64 上运行、可编译 LoongArch64 二进制的 GHC
     • 问题出在 stage2：后续重复构建时，无法正确“喂”入对应的工具链和库，导致 libs-install 和 stage2 阶段失败

6. 问题归因与展望

   • 上游（456）暗示，直接交叉编译 GHC 主体存在困难
   • 龙芯社区已有成功案例，说明可能是构建流程或 Nixpkgs 假设不匹配所致
   • 解决此处问题，有望同时破解 RISC-V 平台的本地编译难题

[Aleksanaa]

还是需要把hadrian/build拆成几个阶段，每个阶段放进自己的derivation。这样才比较可能干净地解决这个问题。交叉编译可以先在一般发行版上尝试分步运行，试好了再往Nixpkgs上搬。

[wegank]

上游的 OpenJDK 24 可能会依赖 pandoc：NixOS#397129

[definfo]

LoongArch64 NCG 进入主线：https://gitlab.haskell.org/ghc/ghc/-/commit/652cba7ee71d2ebd0af912fcc218bc0f27237738
暂未验证可用性

[Moraxyc]

基于 Moraxyc@5086a66 尝试构建出了pkgsCross.loongarch64-linux.haskell.packages.ghc984.ghc

Cache:

nix-store -r \
  --option binary-caches 'https://cache.nixos.org/ https://moraxyc.cachix.org' \
  --option trusted-public-keys '
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  moraxyc.cachix.org-1:p00BlzhjSZq23aXYuzeUF2uXdE8ikh6tq9aV1seenhQ=
  ' \
  /nix/store/7wmwc41vrrbqi86pdl6sjg177wmcw90a-loongarch64-unknown-linux-gnu-ghc-9.8.4 \
  /nix/store/mvr5svlnizk3jnigmb4z39qf9hdbl8hl-loongarch64-unknown-linux-gnu-ghc-9.8.4-doc

我不太明白怎么用该包作为native loongarch64-linux上的bootpkg

[wegank]

我不太明白怎么用该包作为native loongarch64-linux上的bootpkg

@darkyzhou 发现这个包并不 native。验证了一下，确实如此：

$ file /nix/store/7wmwc41vrrbqi86pdl6sjg177wmcw90a-loongarch64-unknown-linux-gnu-ghc-9.8.4/lib/loongarch64-unknown-linux-gnu-ghc-9.8.4/bin/loongarch64-unknown-linux-gnu-ghc-9.8.4
/nix/store/7wmwc41vrrbqi86pdl6sjg177wmcw90a-loongarch64-unknown-linux-gnu-ghc-9.8.4/lib/loongarch64-unknown-linux-gnu-ghc-9.8.4/bin/loongarch64-unknown-linux-gnu-ghc-9.8.4: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /nix/store/g2jzxk3s7cnkhh8yq55l4fbvf639zy37-glibc-2.40-66/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.10.0, not stripped

[darkyzhou]

基于 Moraxyc@5086a66 尝试构建出了pkgsCross.loongarch64-linux.haskell.packages.ghc984.ghc

Cache:

nix-store -r \
  --option binary-caches 'https://cache.nixos.org/ https://moraxyc.cachix.org' \
  --option trusted-public-keys '
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  moraxyc.cachix.org-1:p00BlzhjSZq23aXYuzeUF2uXdE8ikh6tq9aV1seenhQ=
  ' \
  /nix/store/7wmwc41vrrbqi86pdl6sjg177wmcw90a-loongarch64-unknown-linux-gnu-ghc-9.8.4 \
  /nix/store/mvr5svlnizk3jnigmb4z39qf9hdbl8hl-loongarch64-unknown-linux-gnu-ghc-9.8.4-doc

我不太明白怎么用该包作为native loongarch64-linux上的bootpkg

谢谢你的工作，不过你的 GHC 包似乎是个 Stage 1 的包，我们理论上需要 Stage 2 包（即能够在龙架构上运行、编译出龙架构代码），这也是 Aleksanaa 在上面提到的

[Moraxyc]

谢谢你的工作，不过你的 GHC 包似乎是个 Stage 1 的包，我们理论上需要 Stage 2 包（即能够在龙架构上运行、编译出龙架构代码），这也是 Aleksanaa 在上面提到的

抱歉，忽略了关于stage2部分的内容，我会继续尝试能否构建出stage2

[definfo]

谢谢你的工作，不过你的 GHC 包似乎是个 Stage 1 的包，我们理论上需要 Stage 2 包（即能够在龙架构上运行、编译出龙架构代码），这也是 Aleksanaa 在上面提到的

抱歉，忽略了关于stage2部分的内容，我会继续尝试能否构建出stage2

按照之前的经验，目前 Hadrian 仅在 host=build 时工作，常规交叉编译 stage2 编不出 native ghc

[darkyzhou]

从 Debian Ports 仓库 http://ftp.ports.debian.org/debian-ports/pool-loong64/main/g/ghc 获得了龙芯官方人员适配的 GHC 9.6.6 包（LLVM Backend），已经将它打为 Nix 包，明天试试用它作为 bindist 自举 GHC 9.8.4。

稍微研究了 Debian 的打包流程，没有发现和 common-hadrain.nix 的有明显差异。目前还是不清楚 Debian 上的 9.6.6 是如何使用 Hadrain 打出来的（是交叉编译？还是龙芯内部用更早的支持 make 的版本自举出来的？）

[lrzlin]

稍微研究了 Debian 的打包流程，没有发现和 common-hadrain.nix 的有明显差异。目前还是不清楚 Debian 上的 9.6.6 是如何使用 Hadrain 打出来的（是交叉编译？还是龙芯内部用更早的支持 make 的版本自举出来的？）

Debian 的 ghc 来自我最早在适配 LLVM 后端时构建的 unregisterised ghc 9.0.2，在 ghc 9.4 之前使用 makefile 构建系统可以在 x86 正常构建出运行在 loongarch 上的 ghc，很遗憾，后来的 hadrain 构建系统反而丧失了这个能力。目前上游社区有一个 MR 正在做 hadrain 修复的工作：https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11444，可以选择等待这个 MR 合并后进行 backport，或者直接使用 Debian 的 ghc 作为 bindist 自举，不过后者是否符合 nix 的相关规范？

[definfo]

稍微研究了 Debian 的打包流程，没有发现和 common-hadrain.nix 的有明显差异。目前还是不清楚 Debian 上的 9.6.6 是如何使用 Hadrain 打出来的（是交叉编译？还是龙芯内部用更早的支持 make 的版本自举出来的？）

Debian 的 ghc 来自我最早在适配 LLVM 后端时构建的 unregisterised ghc 9.0.2，在 ghc 9.4 之前使用 makefile 构建系统可以在 x86 正常构建出运行在 loongarch 上的 ghc，很遗憾，后来的 hadrain 构建系统反而丧失了这个能力。目前上游社区有一个 MR 正在做 hadrain 修复的工作：gitlab.haskell.org/ghc/ghc/-/merge_requests/11444，可以选择等待这个 MR 合并后进行 backport，或者直接使用 Debian 的 ghc 作为 bindist 自举，不过后者是否符合 nix 的相关规范？

我的担心是上游 MR 状态不容乐观，合并可能遥遥无期......
与此同时我准备先 backport 9.12 合入的 NCG，把 LLVM patch 从构建中摘出去，虽然就短期而言 NCG backport 可能也无法上游化 😕

[Aleksanaa]

loongarch64/discussions#8

[darkyzhou]

17acac4

• 整理了一下目前的修改，已经成功构建出可用的 9.8.4，基于 LLVM 18，且顺利编译出 nixfmt。迟点把包传到 cache.nix4loong.cn
• 不过，这里没能引入添加 -mcmodel=medium 的补丁，Debian 9.6.6 的补丁似乎不能直接搬到 9.8.4，会导致 ghc-pkg 二进制运行会出现 SIGBUS。这里可能得麻烦大家看看，不了解 GHC 的构造。
• 和 alek 聊了一下，使用 debian 包作为 bindist 是上游难以接受的，一种折衷的办法是请求龙芯在 loongnix.cn 上发布具有官方性质的 bindist。当然还有一个保底的办法是从更老的支持 make 的版本一步步 bootstrap 上来