经过了数月的等待之后，新世界工具链与LLVM终于完善到了足以提供GHC支持的程度，目前已经完成了GHC编译器在新世界上的编译和测试，补丁已提交上游，但近期内合并的希望不大，因此在这里给出如何在LoongArch上完成GHC编译的详细指南，希望能够帮助到有需要的人。 GHC LoongArch 分支： Files · loongarch-patch · lrzlin / GHC · GitLab (haskell.org) LLVM GHC 后端补丁： ⚙ D137495 [LoongArch] Add GHC Calling Convention (llvm.org) 交叉工具链： loongarch64-clfs-6.3-cross-tools-gcc-full.tar.xz 使用以下命令将 GHC LoongArch 分支克隆至本地 git clone -b loongarch-patch --recurse-submodules https://gitlab.haskell.org/lrzlin/ghc.git GHC Unregisterised 版本编译首先需要交叉编译GHC Unregisterised 版本根据 CLFS 文档中的指南配置好交叉工具链后找到 ghc/m4/ghc_unregisteried.m4 并将其中的 loongarch64 删除将 ghc/libffi-tarballs 和 ghc/libraries/ghc-bignum/gmp/gmp-tarballs 中 libffi 和 gmp 的压缩包替换为支持 LoongArch 的版本之后回到GHC根目录输入 ./boot ./configure CC=$SYSDIR/cross-tools/bin/loongarch64-unknown-linux-gnu-gcc --target=loongarch64-unknown-linux-gnu LD=$SYSDIR/cross-tools/bin/loongarch64-unknown-linux-gnu-ld 配置完成后输入 hadrian/build -j4 进行编译如果在编译中碰到缺少 ncurses 库的报错，请自行编译并将其安装至交叉编译工具链中编译完成后，输入 hadrian/build binary-dist ` 打包二进制分发包，至此 GHC Unregisterised 版本编译完成，可以将其拷贝至 LoongArch 架构机器安装使用。 GHC Registerised 编译 GHC Unregistered 即可满足大多数情况下的使用需要，但如果需要更高的运行效率、更完善的库支持和更完整的功能，则需要编译 GHC Registerised 版本，由于该版本需要 LLVM 后端的支持，而 LLVM 主分支尚未合并 GHC 后端补丁，因此需要自行下载补丁并编译 LLVM。注：以下操作均在 LoongArch 机器上完成首先需要安装之前编译完成的 GHC Unregisterised 版本 ./configure hadrian/build install 之后需要编译并安装 LLVM 克隆 LLVM 主线源码并打上 GHC 后端补丁之后使用如下命令编译安装 cmake .. -G Ninja -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release \ -DBUILD_SHARED_LIBS:BOOL=OFF -DLLVM_ENABLE_LIBCXX:BOOL=OFF \ -DLLVM_LIBDIR_SUFFIX=64 \ -DCMAKE_C_FLAGS="-DNDEBUG" -DCMAKE_CXX_FLAGS="-DNDEBUG" \ -DLLVM_BUILD_RUNTIME:BOOL=ON -DLLVM_ENABLE_RTTI:BOOL=ON \ -DLLVM_ENABLE_ZLIB:BOOL=ON -DLLVM_ENABLE_FFI:BOOL=ON \ -DLLVM_ENABLE_TERMINFO:BOOL=OFF \ -DLLVM_BUILD_LLVM_DYLIB:BOOL=ON \ -DLLVM_LINK_LLVM_DYLIB:BOOL=ON -DLLVM_BUILD_EXTERNAL_COMPILER_RT:BOOL=ON \ -DLLVM_INSTALL_TOOLCHAIN_ONLY:BOOL=OFF \ -DLLVM_TARGET_ARCH=LoongArch -DLLVM_DEFAULT_TARGET_TRIPLE=loongarch64-unknown-linux-gnu ninja && ninja install 由于 GHC 尚不支持最新的 LLVM 16 版本因此需要对进行如下修改： GHC LoongArch 分支代码：将 ghc/llvm-passes 的内容修改为 [ (0, "-passes=module(default<O0>,function(mem2reg),globalopt,function(lower-expect))"), (1, "-passes=module(default<O1>,globalopt)"), (2, "-passes=module(default<O2>)") ] 将 ghc/compiler/GHC/Driver/Pipeline/Execute.hs 第 902 行中的 -tbaa 删除在 ghc/utils/genapply/Main.hs 中添加 #undef UnregisterisedCompiler -- We improperly include *HOST* macros for our target... #include "../../rts/include/ghcconfig.h" -- If the bootstrap compiler is unregisterised it defines -- UnregisterisedCompiler, which implies NO_REGS. But we only want to -- define NO_REGS if building an unregisterised compiler. #undef UnregisterisedCompiler -- ...so that this header defines the right stuff. It is the RTS's host, but -- our target, as we are generating code that uses that RTS. #include "../../rts/include/stg/MachRegsForHost.h" 由于 GHC 在最新的主线移除了对 make 工具的支持，因此我们还需要编译并安装 cabal-install 请自行参考 Cabal Bootstrap 指南进行编译，完成编译后，请注意需要执行一次 cabal update 之后即可进入 GHC 根目录并使用以下指令编译安装 GHC Registerised 版 ./boot ./configure hadrian/build -j4 hadrian/build install TODO: TableNextToCode 支持

需要注意的是，由于 GHC 官方尚不支持 LLVM 15 及以上版本，因此按照以上方式编译出的 GHC Registerised 版本在编译 Haskell 程序时会出现 Unsupported LLVM Version 16 的警告，这虽然不会影响编译程序的正常运行，但会导致 testsuite 无法得到正确的结果，如果想要避免这一问题，需要在编译前修改根目录下的 configure.ac # Here is where we re-target which specific version of the LLVM # tools we are looking for. In the past, GHC supported a number of # versions of LLVM simultaneously, but that stopped working around # 3.5/3.6 release of LLVM. LlvmMinVersion=10 # inclusive LlvmMaxVersion=14 # not inclusive AC_SUBST([LlvmMinVersion]) AC_SUBST([LlvmMaxVersion]) 将此处的 LlvmMaxVersion=14 修改为 17 并重新编译即可

Update: TableNextToCode 支持已经合并入 GHC 上游代码仓库，等待 LLVM 16 发版且 GHC 跟进支持之后即可达到开箱即用的程度。

lrzlin 您好，我是这方面的初学者。关于移植GHC到Loongarch上的具体过程，有一些问题想要请教。比如，交叉编译工具链6.0版本和8.0版本会有区别吗？还有我跟据此教程运行的结果总是会遇到问题。如果您能回复的话，不胜感激。也可以通过邮箱 chenzhanwang@mail.ustc.edu.cn 联系我。

lafudru 具体是什么问题？工具链应该没有区别，LLVM 这边的补丁已经合并，直接拿上游 16 的版本就可以，是卡在交叉编译阶段还是构建 LLVM Backend GHC 阶段？

lrzlin 交叉编译阶段，没能正确编出结果。有出现过各种问题，其中，最顺利的一次，编译出了结果，可是file命令查看_build中的可执行文件仍然显示是X86架构的，不是loongarch架构。而且stage0和stage1文件夹中的文件数量不一致，貌似没能完全运行成功？下面是编译出的结果 ghc/_build/stage0/bin# ls loongarch64-unknown-linux-gnu-ghc loongarch64-unknown-linux-gnu-haddock loongarch64-unknown-linux-gnu-hpc loongarch64-unknown-linux-gnu-runghc loongarch64-unknown-linux-gnu-ghc-pkg loongarch64-unknown-linux-gnu-hp2ps loongarch64-unknown-linux-gnu-hsc2hs loongarch64-unknown-linux-gnu-unlit ghc/_build/stage1/bin# ls loongarch64-unknown-linux-gnu-ghc-pkg loongarch64-unknown-linux-gnu-hp2ps loongarch64-unknown-linux-gnu-hsc2hs ghc/_build/stage1/bin# file loongarch64-unknown-linux-gnu-ghc-pkg loongarch64-unknown-linux-gnu-ghc-pkg: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=e5dd6a511af7f2ab76712dae770d785e9401bdba, with debug_info, not stripped

lrzlin 还有就是，这一步，“将 ghc/libffi-tarballs 和 ghc/libraries/ghc-bignum/gmp/gmp-tarballs 中 libffi 和 gmp 的压缩包替换为支持 LoongArch 的版本”，我不是很清楚怎么处理，要怎么改呢，是从loongarch的机器上apt看看这两个包的版本，然后把这两个压缩包换成此版本就能起作用吗？还有关于工具链的配置，我目前在环境变量中添加了这两条命令，bin目录下是gcc等工具链，然后链接的一些库是在/target/lib64中吗？： export PATH="/home/czw/cross-tools/bin:$PATH" export PATH="/home/czw/cross-tools/target/lib64:$PATH"

GHC LoongArch 新世界移植/编译指南

lrzlin

lafudru 关于交叉编译环境的问题可以参考 CLFS 手册的环境配置部分，链接在 CLFS For LoongArch。libffi 和 gmp 只需要将原来的压缩包换成最新版的 tarballs 就可以了。至于 GHC 的交叉编译部分，不同 stage 之间有差异是正常的，交叉编译需要到 stage2 才能编出 LoongArch 可执行文件，ghc cross compiling，具体可以看一下这里。说明中间有问题异常退出了。我最开始用的 make 交叉编译，后来 GHC 这边把它删掉了，所以具体的问题我可能也无法定位，不过至少你可以把 log 发给我。

lafudru

lrzlin ./configure --target=loongarch64-unknown-linux-gnu CC=/home/loongson/czw/cross-tools/bin/loongarch64-unknown-linux-gnu-gcc CXX=loongarch64-unknown-linux-gnu-g++

```

Configure completed successfully.

Building GHC version : 9.7.20230201

Git commit id : 8ce50c12561856411ea4647fb2d9d1be31c092a4

Build platform : x86_64-unknown-linux

Host platform : x86_64-unknown-linux

Target platform : loongarch64-unknown-linux

Bootstrapping using : /home/loongson/.ghcup/bin/ghc

which is version : 9.2.8

with threaded RTS? : YES

Using (for bootstrapping) : gcc

Using gcc : /home/loongson/czw/cross-tools/bin/loongarch64-unknown-linux-gnu-gcc

which is version : 13.0.1

linker options : -fuse-ld=bfd

Building a cross compiler : YES

Unregisterised : YES

TablesNextToCode : NO

Build GMP in tree : NO

hs-cpp : /home/loongson/czw/cross-tools/bin/loongarch64-unknown-linux-gnu-gcc

hs-cpp-flags : -E -undef -traditional

ar : /home/loongson/czw/cross-tools/bin/loongarch64-unknown-linux-gnu-ar

ld : loongarch64-unknown-linux-gnu-ld

nm : /home/loongson/czw/cross-tools/bin/loongarch64-unknown-linux-gnu-nm

objdump : /home/loongson/czw/cross-tools/bin/loongarch64-unknown-linux-gnu-objdump

ranlib : /home/loongson/czw/cross-tools/bin/loongarch64-unknown-linux-gnu-ranlib

otool : otool

install_name_tool : install_name_tool

windres :

dllwrap :

genlib :

Happy : /home/loongson/.cabal/bin/happy (1.20.1.1)

Alex : /home/loongson/.cabal/bin/alex (3.4.0.0)

sphinx-build :

xelatex :

makeinfo :

git : /usr/bin/git

cabal-install : /home/loongson/.ghcup/bin/cabal

Using LLVM tools

clang : clang

llc : llc

opt : opt

HsColour was not found; documentation will not contain source links

Tools to build Sphinx HTML documentation available: NO

Tools to build Sphinx PDF documentation available: NO

Tools to build Sphinx INFO documentation available: NO

```

./hadrian/build :（有尝试更改primops.txt.pp文件的编码格式解决i问题，但没能解决。）

```

......

#_build/stage0/compiler/build/GHC/Utils/GlobalVars.o

#_build/stage0/compiler/build/GHC/CmmToAsm/Reg/Graph/X86.o

#_build/stage0/compiler/build/GHC/CmmToAsm/Wasm/Utils.o

#_build/stage0/compiler/build/GHC/CmmToAsm/CFG/Dominators.o

Error when running Shake build system:

at action, called at src/Rules.hs:38:19 in main:Rules

at need, called at src/Rules.hs:60:5 in main:Rules

* Depends on: _build/stage0/lib/package.conf.d/ghc-9.7.conf

at need, called at src/Rules/Register.hs:140:5 in main:Rules.Register

* Depends on: _build/stage0/compiler/build/stamp-ghc-9.7

at need, called at src/Rules/Library.hs:144:3 in main:Rules.Library

* Depends on: _build/stage0/compiler/build/primop-docs.hs-incl

* Raised the exception:

_build/stage0/compiler/build/primops.txt: hGetContents: invalid argument (invalid byte sequence)

Build failed.

```

lafudru

对，它的编译过程是异常退出的，这个我再研究研究，如果解决不了，再来向您求助。关于交叉编译，想请问您后来有用hadrian/build编译过吗，我也是看他教程里其实很多地方都保留了make相关的编译过程，教程貌似没能及时更新。这里是hadrian的README文件，https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/README.md，其中Staged compilation中介绍说，_build/stage1中就应该是运行在target中的版本。

lrzlin

lafudru 可以试一下 tag 9.6.4 版本（LoongArch）支持合入的版本来交叉编译，这个问题可能不是移植引入的问题，最近事情比较多，没时间测试，抱歉。

lafudru

lrzlin 您太客气啦，您的帖子和回复给了我很大帮助。我现在编出了一个用make构建体系的老版本GHC，那里面还没有并入您修改的代码。我后面继续研究一下如何直接编出合并了补丁的高版本，这需要解决一下一些新出现的问题。

liudidi

请问楼主能提供编译好的二进制包吗？自己实在搞不定交叉编译。

REDEAST

liudidi 你用的什么系统，现在新世界的发行版都已经有该包了。
这是Debian的包。
https://mirror.sjtu.edu.cn/debian-ports/pool-loong64/main/g/ghc/

liudidi

REDEAST fedora，没有找到9.6以上的，我试试deb包能不能用。谢谢。

liudidi

终于整个都弄好了，就为了一个pandoc，折腾了快一个月。不过ghc和x86下基本一致了，还算可以。

xiaocaiji

liudidi 大佬，我现在也是在搞这个，不过我这边是申威社区的，我现在是申威社区的ghc无法使用，然后想着自己编译一个又发现ghc依赖于自身，ghc还有一些其他的编译依赖，例如happy，alex编译都需要ghc才行，不知道大佬知道怎么处理的嘛？

xiaocaiji

您好，我当前在一个新的架构上需要编译ghc，发现编译ghc的时候依赖于ghc，这种依赖死锁应该怎么处理呢？因为新架构也没有这种支持

REDEAST

xiaocaiji 这种就需要交叉编译，你可以网上搜一下如何交叉编译ghc

liudidi

xiaocaiji 这个需要交叉编译，但是前提你得移植到新架构上才行。这个贴子的主贴就是讲交叉编译的，你参照一下吧。我是用了debian上已经移植过来的ghc做基础编译的，没用交叉编译。申威架构不熟悉，不太清楚移植起来困难不。不过ghc并不是什么主要的包，没有基本不影响系统使用啊。

本站文章除其作者特殊声明外，一律采用CC BY-NC-SA 4.0许可协议进行授权。
进行转载或二次创作时务必以相同协议进行共享，严禁用于商业用途。