纯手工阶段：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 + GLIBC2.12的搭配引起的），笔者最终统一了各个平台的编译器版本：

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

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