这套工具链原本一直想藏着掖着作为个人的“私服”使用。
但转念一想，随着公司人员的流动，这些底层基建早晚也会流传出去。
与其等别人缝缝补补地发出来，不如自己做个彻底的整理和开源，也算是为国产化平台的快速发展做个贡献吧。

💡 名词速查：

• loongarch64_OA：指代 Loongarch64 Old ABI（龙芯旧世界）
• loongarch64_NA：指代 Loongarch64 New ABI（龙芯新世界）

获取及使用请直接点击此处跳转至文章末尾

🛠️搭建与演进过程

纯手工阶段：mips64el（2020-2021年）

笔者第一次接触交叉编译其实是出于对嵌入式的好奇，买了个开发板。后来在上家公司适配龙芯（mips64el）系统时，遭遇了极端的开发环境：

公司规模很小，甚至没有 Git 和 SVN 服务。每天只能靠着 U 盘把代码小心翼翼地往目标机里单向导入（还不敢插网线）。

为了摆脱这种极其低效的“人肉同步”模式，便开始琢磨：

既然 ARM 平台可以通过 x86 宿主机交叉编译，mips64el 理论上也可以。查阅资料后确认，GCC 源码原生就支持 mips 架构。

于是笔者开始了纯手工构建的踩坑之旅：

从网上到处扒 GCC 的编译参数，手动下载 GMP、MPFR 等各个依赖的源码包，反复调整 --build、--host 以及软硬浮点等底层 ABI 参数。
当时笔者用的是一台兆芯（中标麒麟）的机器，每次改完参数都是临下班前挂起编译，一编就是几个小时，次日早上开盲盒看结果。

在处理了一次次报错后，终于成功构建出了一个能正常工作的交叉编译工具链，并在目标机上跑通了 "Hello World"。

然后笔者发现了龙芯开源社区提供的官方工具链……
艹！

考虑到自行编译 GCC 涉及的参数极其庞杂，万一某个指令集参数配错，基于这套编译器构建的上层工具（比如 Qt）在后期生产环境中也会毁于一旦。
以防万一，最后含泪放弃了手工版本，切换成了官方的 cross-gcc-4.9.3-n64-loongson-rc6.1。

有了底层编译器，下一步就是 Qt。
当时的国产化系统普遍标配 Qt 5.6.1 或 5.6.3，所以笔者就将版本定在了 5.6.3。
当时网上的参考资料大多还带着 Qt4 的历史包袱，需要拷贝 mkspecs/qws 目录下的模板来修改设备配置。
虽然方法老旧，但也总结出了一些奇技淫巧。

总而言之、言而总之。
在 21 年初，笔者算是整体走通了一遍 GCC + Qt 的交叉编译流程。

规模化阶段：arm64 与 loongarch64_OA（2021年）

21年笔者跳槽到了一家初具规模的公司，接触到的国产芯片也多了起来。

此时对于 arm64 的工具链适配就轻车熟路了。
鉴于 arm64 是仅次于 x64 的芯片架构平台，
网上有大量现成的 GCC，笔者只需要挑选基于低版本 GLIBC 构建的工具链即可。
当时选定的是 gcc-linaro-5.4.1-2017.01-x86_64_aarch64-linux-gnu。

对于老龙芯 loongarch64（Old ABI）同样如此，选择了当时开源社区提供的 8.3.0 工具链。

这两者的 Qt 框架全量跨编，完全复用了之前在 mips64el 平台跑通的成功经验，可以说顺利十分。

特殊适配：sw_64（2022年）

申威架构的情况比较特殊。
忌惮于商业保密协议，申威的底层 GCC 工具链笔者无法对外提供。
但笔者针对申威由 Qt 5.6.3 官方源码 编译出来的 Qt交叉编译工具链 完全属于个人的编译产物，不会受此限制。

关于申威的构建技巧无非一层窗户纸：

在配置参数时，将申威指定为其前身 alpha64 架构进行编译。
这是笔者回忆 在上家公司了解各个国产芯片架构发展史 时冒出的 灵感，这几年笔者编译包括 Qt 在内的各种第三方库也反复论证了这个灵感。

(注：sw_64 架构进行过 ABI 版本迭代，不过 Old ABI 的保有量极少。如果遇到，通常建议客户直接升级系统至 New ABI 发行版系统。)

随着龙芯 loongarch64 架构合并至上游 GNU GCC，此前匆忙推出的 旧世界 ABI 因为不满足 GNU 官方规范，自然过渡到了满足 GNU 标准的新世界 ABI（New ABI）。
这也导致了新旧二进制文件不再兼容。

代码合并后，龙芯开源社区并没有及时发布现成的 loongarch64_NA 工具链。
就在这个时候，AI 已经流行并且智商在线了。
笔者查到了一个叫 crosstool-ng 的神器。

唉！
那笔者前几年手搓 mips64el 吃那么多苦是为了什么？

于是，loongarch64_NA 的底层编译器就成了笔者使用 crosstool-ng 自动化构建的首个产物。
同时，它的 Qt 交叉编译流程也终于摆脱了老旧的 qws 模式，正式切回了 Qt5 标准的构建方式。

进化：统一 GCC 8.3+ 与 C++17 矩阵

自从打开了 crosstool-ng 的魔盒，笔者一直在思考一件事：

是否可以通过这个工具，把所有架构的工具链版本全部向申威和龙芯旧世界的8.3版本对齐，使整个项目从C++11进化至C++17？
毕竟C++11的第三方库已经逐渐停止维护。

终于有天笔者按耐不住了……

后续经过一段时间的对各种编译错误的处理（记得主要是GCC 8.3 + GLIBC2.12的搭配引起的），笔者最终统一了各个平台的编译器版本：

构建出了全套基于 GCC 8.3+ 的工具链矩阵。

这使得整个项目可以顺利迭代并支持到 C++17 标准，同时由于严格控制了 glibc 依赖底线。
这套工具链的编译产物依然完美保持了对极老旧生产系统（如 CentOS 6）的部署兼容性。

下载地址

下载前请仔细查阅说明文档
📦 全套 GCC 8.3+ 交叉编译工具链
🎨 全套 Qt 5.6.1+ GUI 交叉编译工具链

关于后续演进

开源不易，全架构的适配与编译更是耗费了笔者大量的时间和精力。 如果这套工具链帮你节约了加班时间，希望大家多多支持打赏并点个 Star ⭐！ 后续，笔者会逐渐升级 Qt 工具链全套为 5.15.xx。 也会尝试构建出能够让 CentOS 6 运行 C++23、26 程序的工具链，让大家体验更优质的开发过程。