行空板 M10 移植 Qt6 实践记录（Debian 10 → Debian 13）

前言
关于行空板 M10 移植 Qt6 的工作，其实在上一篇文章中已经做过初步尝试。不过当时的方案存在不少问题，整体只能算是“跑起来了”，距离稳定可用还有一定差距。
M10 的原生系统是 Debian 10。这个版本在今天来看已经比较老旧，但设备本身仍然基于该系统构建。对于 Qt6 来说，这意味着一个比较现实的问题：基础依赖版本偏旧，很多构建环境需要自行补齐。
在 Debian 10 上尝试编译 Qt6 时，最大的成本并不是 Qt 本身，而是整个工具链和依赖体系，包括 GCC、x11 相关库、图形依赖等，都需要逐步手动解决，甚至部分组件需要通过“自举”的方式构建。
在这样的环境下，虽然最终完成了 Qt6.2 的静态编译，但整体体验并不理想。
________________________________________
上一阶段 Qt6 的情况
在 Debian 10 上，最终只稳定编译成功了 Qt 6.2。更高版本在实际构建过程中会遇到一些难以定位的问题，包括编译错误、依赖缺失以及配置阶段失败等情况。
此外，即使 Qt 6.2 能够正常编译，实际使用也存在一些限制：
•        qmake 工程基本可用
•        CMake 工程兼容性不稳定
•        部分模块功能缺失或行为异常
因此，从工程角度来看，这一阶段的 Qt6 更接近“可运行的最小环境”，而不是完整的 Qt6 开发环境。
________________________________________
本次目标：升级到 Debian 13
基于上述问题，本次工作的主要目标是将 M10 的用户态环境升级到 Debian 13，从而改善 Qt6 的构建和运行条件。
这里采用的策略比较保守：不更换内核，只替换文件系统环境，以尽量保留原有硬件驱动的兼容性。
理论上，也可以通过逐步升级的方式完成系统迁移，例如：
sudo apt update
sudo apt upgrade
sudo apt full-upgrade
逐步从 Debian 10 升级到 11、12，再到 13。
不过在实际过程中，这种方式存在一定风险，例如升级到较新版本后桌面环境可能丢失，原有的图形界面和厂商提供的 Python 控制工具也可能无法继续使用。
从开发角度来看，这些组件并不是必须的，因此影响主要集中在使用体验层面。
________________________________________
Python 硬件支持环境
如果仍然需要保留对 M10 硬件的控制能力，可以重新安装 Python 相关依赖：
sudo apt install python3
pip3 install pinpong
需要注意的是，仅安装库并不一定保证其正常工作，还需要确保系统启动时相关初始化脚本被正确执行。
例如可以在 /etc/rc.local 中加入：
python3 /usr/local/lib/python3.13/dist-packages/pinpong/base/gd32/anaysis.py
否则 pinpong 在部分场景下可能无法完成初始化。
________________________________________
最小图形环境配置
为了运行 Qt GUI 程序，不需要完整桌面环境，只需要一个基础窗口管理器即可：
sudo apt install openbox
openbox 的优势是依赖少、启动快、结构简单，适合作为嵌入式环境下的 Qt 运行基础。
________________________________________
Qt6 移植流程
Qt6 的移植过程本身并不复杂，主要分为三个步骤：
1.        在 QEMU 中搭建 Debian 13 ARM 测试环境
2.        选择合适版本的 Qt6 源码
3.        在目标环境中完成编译与安装
在实际操作中，QEMU 主要用于提前验证编译流程，避免直接在开发板上反复试错。
________________________________________
Qt6 编译配置
本次使用的 configure 参数如下：
../configure \
  -static \
  -release \
  -prefix /opt/Qt/6.2.13-xcb-static \
  -opensource -confirm-license \
  -nomake tests \
  -nomake examples \
  -xcb \
  -xkbcommon \
  -opengl es2 \
  -feature-gstreamer \
  -skip qtwebengine
________________________________________
构建策略说明
这里有几个关键选择需要说明。
1. 静态编译
本次采用静态编译方式：
-static
静态编译的优势在于部署简单，生成的程序不依赖大量动态库，特别适合嵌入式设备环境，可以显著降低运行时依赖问题。
________________________________________
2. 图形后端选择 XCB
在 M10 上，图形后端的选择比较关键。
实际测试中：
•        eglfs 在当前系统上依赖 DRM，但支持不完整
•        linuxfb 存在一定渲染问题，稳定性不足
•        XCB 表现最稳定
因此最终选择 XCB 作为默认图形后端。
虽然 XCB 在性能上并不是最优解，但在当前硬件和系统条件下，它是最稳妥的方案。
________________________________________
总结
这次迁移的核心变化，其实不在 Qt6 本身，而在底层系统环境。
从 Debian 10 切换到 Debian 13 之后，Qt6 的构建和使用体验明显改善，至少从“勉强可用”提升到了“可以作为开发环境使用”的程度。
整体来看，这次工作更像是把基础环境重新整理了一遍，为后续更完整的 Qt6 应用开发打下基础。

________________________________________
PS：笔者拿AI润色了一下文章可能有点AI味不过还是比原文好太多了
最后附一下运行Qt6示例项目的效果


最后附一下运行Qt6示例项目的效果