笔者第一次接触交叉编译其实是出于对嵌入式的好奇买了个开发板。后来在上家公司适配龙芯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_OA2021年21年笔者跳槽到了一家初具规模的公司接触到的国产芯片也多了起来。此时对于 arm64 的工具链适配就轻车熟路了。鉴于 arm64 是仅次于 x64 的芯片架构平台网上有大量现成的 GCC笔者只需要挑选基于低版本 GLIBC 构建的工具链即可。当时选定的是gcc-linaro-5.4.1-2017.01-x86_64_aarch64-linux-gnu。对于 loongarch64Old ABI同样如此选择了当时开源社区提供的8.3.0工具链。这两者的 Qt 框架全量跨编完全复用了之前在 mips64el 平台跑通的成功经验可以说顺利十分。特殊适配sw_642022年申威架构的情况比较特殊。忌惮于商业保密协议申威的底层 GCC 工具链笔者无法对外提供。但笔者针对申威由Qt 5.6.3 官方源码编译出来的 Qt交叉编译工具链 完全属于个人的编译产物不会受此限制。关于申威的构建技巧无非一层窗户纸在配置参数时将申威指定为其前身alpha64架构进行编译。这是笔者回忆在上家公司了解各个国产芯片架构发展史时冒出的灵感这几年笔者编译包括 Qt 在内的各种第三方库也反复论证了这个灵感。(注sw_64 架构进行过 ABI 版本迭代不过 Old ABI 的保有量极少。如果遇到通常建议客户直接升级系统至 New ABI 发行版系统。)自动化重构loongarch64_NA 与 crosstool-ng2026年随着龙芯 loongarch64 架构合并至上游 GNU GCC此前匆忙推出的 旧世界 ABI 因为不满足 GNU 官方规范自然过渡到了满足 GNU 标准的新世界 ABINew ABI。这也导致了新旧二进制文件不再兼容。代码合并后龙芯开源社区并没有及时发布现成的 loongarch64_NA 工具链。就在这个时候AI 已经流行并且智商在线了。笔者查到了一个叫crosstool-ng的神器。唉那笔者前几年手搓 mips64el 吃那么多苦是为了什么于是loongarch64_NA 的底层编译器就成了笔者使用 crosstool-ng 自动化构建的首个产物。同时它的 Qt 交叉编译流程也终于摆脱了老旧的 qws 模式正式切回了 Qt5 标准的构建方式。进化统一 GCC 8.3 与 C17 矩阵自从打开了 crosstool-ng 的魔盒笔者一直在思考一件事是否可以通过这个工具把所有架构的工具链版本全部向申威和龙芯旧世界的8.3版本对齐使整个项目从C11进化至C17毕竟C11的第三方库已经逐渐停止维护。终于有天笔者按耐不住了……后续经过一段时间的对各种编译错误的处理记得主要是GCC 8.3 GLIBC2.12的搭配引起的笔者最终统一了各个平台的编译器版本构建出了全套基于 GCC 8.3 的工具链矩阵。这使得整个项目可以顺利迭代并支持到C17标准同时由于严格控制了 glibc 依赖底线。这套工具链的编译产物依然完美保持了对老旧生产系统如CentOS 6的部署兼容性。