这套工具链原本一直想藏着掖着作为个人的“私服”使用。

但转念一想，随着公司人员的流动，这些底层基建早晚也会流传出去。

与其等别人缝缝补补地发出来，不如自己做个彻底的整理和开源，也算是为国产化平台的快速发展做个贡献吧。

名词速查：

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

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

    这使得整个项目可以顺利迭代并`支持`到 `C++17` 标准，同时由于严格控制了 glibc 依赖底线。

    这套工具链的编译产物依然完美保持了对老旧生产系统（如 `CentOS 6`）的部署`兼容性`。

下载地址

    下载前请仔细查阅自述文档

    随后再进入`release`页面下载

     全套 GCC 8.3+ 交叉编译工具链

     全套 Qt 5.6.1+ GUI 交叉编译工具链

转载望注明出处

关于后续演进

 开源不易，全架构的适配与编译更是耗费了笔者大量的时间和精力。

如果这套工具链帮你节约了加班时间，希望大家多多支持打赏并点个 Star ⭐！

后续，笔者会逐渐升级 Qt 工具链全套为 5.15.xx。

也会尝试构建出能够让 CentOS 6 运行 C++23、26 程序的工具链，让大家体验更优质的开发过程。

该文章转载源至笔者本人博客园

[招生]科锐逆向工程师培训(2026年7月3日实地，远程教学同时开班, 第56期)！