用 GPT-5 完成 Flutter/Dart 的 LoongArch 全栈移植：从 Dart VM 到 Flutter Engine 与 eLinux

项目地址：
https://github.com/Flutter-Dart-loong64
本文记录截至 2026 年 8 月 7 日 Flutter-Dart-loong64 项目的实际开发状态。
本文涉及的项目状态主要依据当前维护分支、源码、近期提交以及实际 Release 整理，而不是单纯依据 README。

先说这个项目最特殊的地方

Flutter-Dart-loong64 的 Flutter / Dart LoongArch 移植代码整体由 GPT-5 完成。

这里说的不是“GPT-5 帮忙查了点资料”，也不仅仅是：

给出移植建议；
做代码 Review；
分析编译错误；
做风险评估。

而是实际参与并完成移植代码的生成、修改、上游同步适配、构建系统修改以及大量兼容性修复。

涉及范围已经覆盖：

Dart VM
Dart Compiler
LoongArch Assembler
JIT / AOT
FFI / ABI
Flutter Tool
Flutter Engine
Linux GTK Embedder
OpenGL / EGL
LoongGPU
Native Assets
Skia
SPIR-V
eLinux
X11
Wayland
DRM / GBM
Rust / C / C++ 原生依赖

所以这个项目更准确的描述并不是：

人工完成 Flutter LoongArch 移植，GPT-5 作为辅助工具。

而是：

以 GPT-5 作为主要代码实现者，对 Dart、Flutter 及相关依赖进行持续的 LoongArch 架构移植。

当然，GPT-5 写完代码和某项功能已经得到真实硬件验证是两件不同的事。

项目一直把状态分成几个层级：

代码已实现
    ↓
编译通过
    ↓
链接通过
    ↓
真实 LoongArch 系统启动
    ↓
真实 Flutter 应用运行
    ↓
真实 GPU / 显示后端 / 硬件验证

因此没有经过真实环境验证的功能，即使代码已经完成，也不会直接宣称“完全支持”。

这点在后面讲 GPU、DRM/KMS、Vulkan 时尤其重要。

一、这已经不是一个 Flutter Patch

很多人第一次看到 Flutter LoongArch 移植，可能会觉得只是给 Flutter 加：

loong64

这个架构名称。

实际上 Flutter 的底层依赖链非常长。

完整链路大致是：

Flutter Application
        ↓
Flutter Framework
        ↓
Flutter Tool
        ↓
Dart SDK / Dart VM
        ↓
Flutter Engine
        ↓
Skia / Impeller
        ↓
GTK / EGL / OpenGL / Vulkan
        ↓
Linux ABI / libc / Toolchain
        ↓
GPU Driver / Display Server

任何一层不认识 LoongArch，最终都会出问题。

例如 Dart VM 不支持 LoongArch，那么：

dart

自己就运行不了。

Dart 能运行，但 Flutter Tool 不认识 Host Architecture，那么：

flutter build linux

仍然不会选择正确 Engine。

Flutter Tool 能运行，但 Engine 没有 LoongArch：

libflutter_linux_gtk.so

仍然不存在。

Engine 能编译，但 FFI ABI 错误，大量插件又会崩。

再往下还有：

Skia
Native Assets
SPIR-V
Rust crates
GTK
Mesa
EGL
LoongGPU

所以最后就自然形成了现在这一组仓库。

目前 Flutter-Dart-loong64 组织维护的公开仓库包括：

仓库	主要作用
`sdk`	Dart SDK / Dart VM LoongArch 后端
`flutter`	Flutter Framework、Flutter Tool 与当前 Engine 源码
`engine`	早期独立 Flutter Engine Loong64 移植
`flutter-elinux`	eLinux Flutter CLI
`flutter-embedded-linux`	Sony Embedded Linux Embedder
`flutter-loong64-releases`	新世界 Flutter SDK 发布
`flutter-loongarch64-releases`	UOS 20 等旧世界 SDK
`flutter-kylin-v10-loongarch64-releases`	麒麟 V10 SP1 旧世界 SDK
`native`	Dart Native Assets
`pub-packages`	Loong64 Native Assets 临时包镜像
`skia`	Skia 相关适配
`SPIRV-Cross`	SPIR-V 转换工具兼容
`vulkan-deps`	Vulkan/SPIR-V 构建依赖版本管理
`rustdesk`	大型 Flutter + Rust 应用验证
`flutter-linglong-store`	Flutter Linux 实际应用验证
`nix`	Rust nix crate LoongArch 兼容
`mozjpeg`	MozJPEG
`mozjpeg-sys`	MozJPEG Rust FFI
`mozjpeg-rust`	MozJPEG Rust 包
`.github`	Organization 公共信息

这些仓库并不是随便 Fork 一堆项目，而是移植过程中实际遇到依赖缺口以后逐渐形成的。

二、新世界和旧世界必须先分清

整个 LoongArch Linux 生态里最容易踩坑的地方，就是新旧世界 ABI。

在这个项目中目前主要这样区分。

LoongArch 新世界

项目内主要使用：

loong64
linux-loong64

典型 ELF Interpreter：

/lib64/ld-linux-loongarch-lp64d.so.1

主要目标包括：

UOS 25
deepin 25
其他 LoongArch 新世界发行版

LoongArch 旧世界

旧世界单独维护：

oldworld/loongarch64-main
oldworld/loongarch64
oldworld-loongarch64

典型目标包括：

UOS 20
Kylin V10 SP1

典型 ELF Interpreter：

/lib64/ld.so.1

这两套 ABI 不能简单混用。

这也是为什么项目里同时存在：

flutter-loong64-releases

和：

flutter-loongarch64-releases

两套发布渠道。

Dart SDK、Flutter Engine、gen_snapshot、C++ Runtime、Skia 以及 eLinux Backend 都需要考虑这个 ABI 边界。

Dart SDK 当前也确实分别维护 loong64-main 与多条 old-world 分支。

三、Dart VM：真正加入了 LoongArch 后端

整个项目最核心的部分是：

Flutter-Dart-loong64/sdk

如果 Dart VM 没有真正的 LoongArch Backend，后面的 Flutter 都没有意义。

当前代码已经能看到完整的 LoongArch 专用实现。

包括：

runtime/platform/globals.h