这套工具链原本一直想藏着掖着作为个人的“私服”使用。
但转念一想，随着公司人员的流动，这些底层基建早晚也会流传出去。
与其等别人缝缝补补地发出来，不如自己做个彻底的整理和开源，也算是为国产化平台的快速发展做个贡献吧。
💡 名词速查：
- 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_NA 与 crosstool-ng （ 2026 年）
随着龙芯 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 + GLIBC 2.12 的搭配引起的），笔者最终统一了各个平台的编译器版本：
构建出了全套基于 GCC 8.3+ 的工具链矩阵。
这使得整个项目可以顺利迭代并支持到 C++17 标准，同时由于严格控制了 glibc 依赖底线。
这套工具链的编译产物依然完美保持了对老旧生产系统（如 CentOS 6）的部署兼容性。
🔗 下载地址
下载前请仔细查阅自述文档，随后再进入 release 页面下载。
转载望注明出处
关于后续演进
开源不易，全架构的适配与编译更是耗费了笔者大量的时间和精力。
如果这套工具链帮你节约了加班时间，希望大家多多支持，去 GitHub 点个 Star ⭐！
后续，笔者会逐渐升级 Qt 工具链全套为 5.15.xx 。
也会尝试构建出能够让 CentOS 6 运行 C++23 、26 程序的工具链，让大家体验更优质的开发过程。
Select Language