[Feature] 求个linux arm版本

[SivanHu]

Problem / 问题

如题，目前看着没有linux的arm版本，能否增加一个.appimage的linux arm版本

Proposed change / 期望改动

1

Alternatives / 其他方案

No response

Additional context / 补充信息

No response

[muzimu217]

Hi @vastsa，关于 #163 提到的 ARM 版本需求，我在自己 fork 上做了一轮完整验证，同步一下结果，看看社区是否有兴趣把它纳入官方支持。

痛点

鲲鹏、AWS Graviton、Ampere 等 ARM64 服务器/开发板越来越常见，但官方 Linux 包目前只有 x64，ARM 用户没有可用的安装包。

我做了一版并验证过的东西

全部在我 fork 的 exp/linux-arm64 分支，用 GitHub ubuntu-22.04-arm runner 构建（CI 工作流，验证 run）：

• arm64 三件套可正常构建：AppImage / deb / rpm，无 x64 串味，electron-builder 自动产出 latest-linux-arm64.yml（发布配置无需手改）
• deb 在 arm64 Ubuntu 22.04 上安装成功、应用正常启动
• host-core 后端握手成功——CI 冒烟测试里加了硬断言，日志必须出现 host-core handshake ok 否则直接 FAIL，这轮是真实通过的
• UI 完整渲染，真实启动截图（无 headless 空屏）：

构建包已挂在 fork release，方便 ARM 用户直接试用：v0.14.6-rc.3-arm64-exp

实现思路

linux target 去掉 per-target arch 数组，改由 CLI --arm64 注入架构（与现有 macOS matrix 的做法一致），不碰 macOS/Windows 任何逻辑。

发现的一个边界问题

构建基线 glibc 2.35 会把 EulerOS 2.0（glibc 2.34）这类发行版挡在门外：UI 能渲染，但 host-core 后端会被 assertLinuxGlibcSupported() 在启动前拦截（我在鲲鹏 + EulerOS 真机上实测确认）。国内不少 ARM 服务器跑欧拉系，这个基线是否值得讨论（降基线或按需构建），想听听官方的看法。

如果官方有兴趣

我可以把改动整理成 PR 提过来（改动很小，主要集中在 linux target 配置 + arm64 冒烟测试）。谢谢！

[SivanHu]

glibc能支持更低的版本吗？国产麒麟系统的glibc会更低一些

[muzimu217]

好问题。刚好分析了一下我们 arm64 包的二进制：Electron 壳最高只引用 GLIBC_2.25 符号，Rust host-core 最高 GLIBC_2.34——应用里显示的 "needs 2.35" 是启动策略检查，高于二进制真实底线（host-core 在 glibc 2.34 的 EulerOS 上可以直接运行）。

所以 openEuler 22.03 / EulerOS（2.34）改一下策略常量就能支持；麒麟 V10（2.28）需要低基线重编 host-core。我这边打算尝试做一下低基线验证，有结果再回来反馈。

[muzimu217]

低基线验证做完了，麒麟 V10 这条路是通的：

在 openEuler 20.03 容器（glibc 2.28）里重编 host-core，符号地板自动钉在 GLIBC_2.28（CI 硬断言通过，run 34432399361），二进制在 2.28 环境真实启动。Electron 壳本身只引用 GLIBC_2.25，不用动。

低基线 host-core 已传到 release（pi-desktop-host-core-glibc228-aarch64）。

欢迎麒麟 / openEuler 20.03 的朋友帮忙测试，两条命令：

# 1. 先装标准 arm64 包（rpm/deb 均可，见 release）
# 2. 换低基线 host-core + 放宽启动检查（等长替换，不破坏包结构）
sudo cp pi-desktop-host-core-glibc228-aarch64 /opt/PI-Desktop/resources/bin/pi-desktop-host-core
sudo python3 -c "
d=open('/opt/PI-Desktop/resources/app.asar','rb').read()
open('/opt/PI-Desktop/resources/app.asar','wb').write(d.replace(b'minor: 35',b'minor: 28'))"

然后正常启动 pi-desktop --no-sandbox --disable-gpu，日志里看到 host-core handshake ok 就是全链路通了（欢迎把结果反馈到这个 issue）。

说明：那个 minor: 35 是应用自己的启动策略检查，高于二进制真实需求——等官方确认支持策略后（降常量或双基线构建矩阵），这些手动步骤就都不需要了。构建脚本都在 fork 的 exp/linux-arm64 分支，需要的话我整理进 PR。