在 Linux 下做一款压缩工具的跨架构适配听起来像是个简单的编译任务。其实标题这句话已经把事情说透了PeaZip 11 在 Linux 上要同时交付 amd64、arm64 和龙芯loongarch64三个可用版本。做之前我以为只是把构建参数改一改真正跑起来才发现光是让三个架构的依赖库对齐就已经花掉大半个周末。这篇文章是这次适配过程的全记录把我踩过的坑、验证过的方法、最终采用的打包方案都写出来给正好也在折腾跨架构 Linux GUI 工具的朋友做个参考。1. 为什么 PeaZip 11 值得做 Linux 多架构适配1.1 PeaZip 在 Linux 生态里的定位PeaZip 是一款开源的图形化压缩工具界面用 Lazarus/FreePascal 开发核心压缩能力通过调用 7-Zip、p7zip、bsdtar 等后端引擎实现。它的看家本领是格式覆盖广7z、zip、tar、gz、bz2、xz、zstd、rar 解压以及自解压、分卷、加密、校验等高级功能。Linux 桌面自带的归档管理器比如 GNOME 的 File Roller 和 KDE 的 Ark日常解压 zip/tar 完全够用但碰到冷门格式或者需要分卷加密的场景就力不从心了。PeaZip 正好把这块补上这也是它在 Linux 用户里一直有固定受众的原因。不过 PeaZip 官方对 Linux 的架构支持一直偏向 x86 体系。早期只有 amd64 和 i386 包后来慢慢有了 arm64 版本。真正把龙芯 loongarch64 纳入构建目标是最近社区里呼声很高的一件事。原因也不难理解使用 ARM 设备的 Linux 用户越来越多树莓派、RK3588 盒子、鲲鹏服务器、苹果 M 系列跑 Linux 虚拟机都需要 arm64 原生包龙芯的 loongarch64 设备在国产化办公环境里大批量铺开但应用生态相对薄弱用户想装个顺手的压缩工具经常只能找源码自己折腾。1.2 amd64、arm64、loongarch64 到底有什么差别很多用户对这几个架构名是懵的。amd64 就是平时说的 x86_64几乎所有家用 PC 和主流服务器都在用指令集成熟软件生态最全。arm64 也叫 AArch64是 ARM 公司的 64 位指令集手机处理器、苹果 M 系列、树莓派、大量云厂商的 ARM 实例都是这个架构特点是功耗低、核心数多能效比好。loongarch64 是龙芯的自主 64 位指令集跟前面两者完全不兼容既不能直接运行 x86 程序也不能运行 ARM 程序。操作系统层面的区别同样关键。Debian/Ubuntu 的包架构名里amd64 对应 x86_64arm64 对应 AArch64loongarch64 在不少仓库里写作 loong64也有叫 loongarch64 的。这意味着做软件分发时不但二进制要重新编译打包系统的架构字段、依赖声明、安装判断逻辑都得跟着改。用一句话总结就是这三种架构之间的指令集、ABI、系统库都不通用不能指望一个 amd64 的 deb 包在龙芯上还能跑也不存在拷贝个 arm64 二进制到龙芯就能用这种好事。架构指令集常见设备包架构名Debian 系amd64x86_64PC、主流服务器amd64arm64AArch64树莓派、M 系列、ARM 云实例arm64loongarch64LoongArch64龙芯 3A5000/3A6000 等loong64 / loongarch641.3 这次适配的真实动机我最开始只是想在树莓派上装个 PeaZip结果发现官方虽然放了 arm64 包但版本经常比 amd64 落后而且依赖处理得很粗糙。后来在龙芯设备上试跑发现连像样的安装包都没有只能找旧版源码手工编译编译过程中还因为 FreePascal 编译器版本太老、Lazarus 组件包不匹配折腾了一整晚。做这个适配项目说白了就一个目标让 amd64、arm64、loongarch64 三种架构的用户都能拿到同一版本的 PeaZip 11 安装包下载安装就能用不需要自己编译也不需要在 x86 模拟层里忍受性能损失。2. 构建环境不是所有架构都能编译一时爽2.1 主工具链Lazarus/FreePascal 的版本门槛PeaZip 的图形界面是基于 Lazarus 的 LCL 组件库写的所以构建它必须先有 Lazarus IDE 和 Free Pascal CompilerFPC。这里第一个坑就来了FPC 对 loongarch64 的支持是很晚才加入的。如果你用的是发行版软件源里自带的 FPC 3.2.0那基本可以放弃龙芯目标因为编译器后端根本不认识 LoongArch 指令集。实测需要 FPC 3.2.2 以上的版本或者直接用 FPC 主线快照。Lazarus 也要注意2.2.6 及以后版本对 LCL 的跨平台编译支持才比较完整建议直接上 Lazarus 3.x 配合最新稳定版 FPC。另一个容易忽略的是 fpcsrc 源码路径。FPC 在编译 LCL 组件时需要引用自身的 RTU 源码。不同发行版对 FPC 目录布局的约定不一样Debian/Ubuntu 一般装在/usr/lib/fpc/src龙芯的 Loongnix 系统里可能装在/usr/share/fpcsrc。如果路径不对编译时会报找不到system单元之类的错看起来像是编译器损坏其实只是FPCDIR或fpc.cfg里的路径配置问题。建议在开始构建前先手动跑一遍fpc -i确认默认路径再用fpcdir/usr/lib/fpc/src这样的参数强制指定能省去很多无效排查。2.2 交叉编译还是原生构建怎么选跨架构 GUI 应用第一个要决策的是用交叉编译还是原生编译。我的经验是核心原则是能用原生就原生。交叉编译要解决编译器之外的整套运行库问题比如目标架构的 GTK2/Qt 库、D-Bus 库、X11 库这些一旦缺了编译期报错五花八门排查成本高。amd64 没有任何悬念直接在 x86_64 机器上原生构建arm64 采用了一个折中方案先用交叉编译把主程序编出来再在一台真机 ARM 设备上做make install和运行验证loongarch64 则直接找了个龙芯 3A5000 的真机做原生构建虽然编译速度慢一点但省掉了交叉工具链缺失带来的巨大麻烦。这里要特别说下 FPC 的交叉编译方式。FPC 交叉编译不像 Go 那样设置两个环境变量就完事它需要先安装目标平台的交叉 binutils 和交叉 FPC 单元库。以 arm64 为例# 安装 arm64 交叉工具链 sudo apt install binutils-aarch64-linux-gnu gcc-aarch64-linux-gnu # 使用 fpcupdeluxe 安装 lazarus aarch64 交叉版本推荐 # 选择 cross-* 前缀的组件即可用 fpcupdeluxe 的好处是它会自动拉对应架构的 LCL 单元并处理好目标平台的 RTL 和 packages。如果嫌 GUI 工具麻烦也可以在命令行执行make clean all OS_TARGETlinux CPU_TARGETaarch64 CROSSBINDIR/usr/aarch64-linux-gnu/bin不过这招对纯命令行程序可行对需要 LCL 界面组件的程序后面的路还长。2.3 压缩引擎的架构二进制准备很多人以为编译完 PeaZip 主程序就结束了这是对 PeaZip 架构的一个常见误解。PeaZip 的 GUI 只是个管理壳真正执行压缩解压动作的是它调用的 7zz、7za、bsdtar 等外部引擎。所以一个完整可用的 PeaZip 包必须同时包含这些引擎的可执行文件而且它们必须和目标平台架构匹配。对于 amd647-Zip 官方直接提供 linux-x64 的二进制爽快。对于 arm647-Zip 同样有 aarch64 构建或者从源码编译也能拿到。比较麻烦的是 loongarch64官方发布渠道没有现成的 loongarch64 可执行文件只能从 7-Zip 源码自己编。7-Zip 官方源码在CPP/7zip/Bundles/Format7zF目录下用 make 构建编译倒是比较顺利毕竟它是纯 C CLI 工具不依赖图形库。交叉编译也行但建议在龙芯真机上原生跑一版能少踩很多编译器指令兼容的坑。准备好引擎后还有一个细节PEAZIP 在运行时通过配置查找这些工具的位置默认会优先找主程序同目录下的可执行文件。打包时一定要把7zz、7za、bsdtar、peazip放对位置并设置好可执行权限否则用户拿到手会发现界面正常点解压却没反应。3. 三架构构建实战与踩坑记录3.1 amd64 基线包先跑通默认流程做多架构适配不能一开始就扑到最难的目标上正确顺序是先拿 amd64 做基线。我从 PeaZip 官方源码包开始在 Ubuntu 22.04 上安装 Lazarus 3.2进入源码目录执行自带的构建脚本。脚本会依次编译各个子组件最终生成peazip可执行文件。这个阶段基本顺利唯一的坑是脚本依赖的gresource工具如果没有安装资源编译会失败需要补上libglib2.0-dev-bin。基线跑通之后手动运行一遍源码目录里的peazip确认界面能弹出然后压缩一个目录、解压一个 7z 包功能链路通了才说明 GUI 和后端引擎的调用关系正常。这个基线包的价值在于后续 arm64 和 loongarch64 出现任何奇奇怪怪的问题都可以拿 amd64 的行为做对比判断是代码本身的问题还是架构移植引入的问题。3.2 arm64 交叉编译缺的不是编译器是 GUI 依赖arm64 交叉编译我踩的最大的坑不在 FPC 本身而在 LCL 组件依赖的系统库。LCL 在 GTK2 的 widgetset 下编译需要找到 arm64 版本的 GTK2 开发头文件。可是宿主机装的是 x86_64 的系统库直接交叉编译会报gtk/gtk.h: No such file or directory。这时候才意识到要用多架构支持sudo dpkg --add-architecture arm64 sudo apt update sudo apt install libgtk2.0-dev:arm64 libc6-dev:arm64这一步在 x86_64 的 Ubuntu 22.04 上是可以走通的但某些 ARM 第三方源里的包版本可能不齐需要手动添加 ports 源。相比之下用带桌面环境的 arm64 真机做原生构建要省心很多直接在树莓派或者 ARM 开发板上装好 Lazarus跑同一套构建脚本中间不涉及任何 cross 参数出错概率低很多。实测下来我最终推荐 arm64 也用原生构建除非你要在 CI 流水线里批量生成才值得把交叉编译的坑一次性踩平。3.3 loongarch64 龙芯版问题最集中龙芯版是整个适配过程里问题最集中的一块。首先是工具链在龙芯设备上安装 Lazarus 3.x 并不像 x86 那样apt install lazarus就能拿到对应版本Loongnix 软件源里的 Lazarus 往往陈旧。解决方案要么自己下载 Lazarus 对 loongarch64 的预编译包要么从源码逐步编译 FPC 再到 Lazarus。这里我强烈建议直接用预编译包因为 FPC 的 bootstrap 链条比较长源码来自举耗时太可观。第二个坑是 Glibc 版本兼容。PeaZip 11 在较新发行版上编译默认链接到较新的 Glibc放到老版本的龙芯系统上运行时会报version GLIBC_2.34 not found这个问题在红帽系系统上尤其明显。我们后来统一在较老的兼容基础环境上编译或者对二进制做 patch保证最低满足 GLIBC_2.32 左右这样龙芯设备上的大多数系统都能跑。第三个坑是 Qt 和 GTK2 的选择。龙芯设备的桌面环境五花八门有的基于 GTK有的用 Qt。PeaZip 在 Linux 下可以用 GTK2 widgetset 也可以编译成 Qt5 版本。为了兼容性我选择保留 GTK2 构建因为这个依赖在老系统上更常见。但在部分只预装 Qt 库的精简系统上就要额外装libgtk2.0-0和相应依赖否则启动直接报缺库错误。3.4 编译期摸黑排查的一个通用套路遇到编译失败我的经验是先分清是三类问题里的哪一类第一类FPC 编译器本身不支持目标 CPU一般会报 illegal instruction 或 operand type mismatch这时只能升级编译器第二类目标架构的系统库缺失一般是找不到某个.h文件或.so文件这时要回到包管理器解决依赖第三类源码里的汇编或内嵌汇编不是跨平台的常见于一些深度优化的第三方库这时要么换成纯 C 实现要么用条件编译跳过。把问题归类后至少不会被编译器的一长串输出绕晕。4. 打包与分发deb、rpm、AppImage 怎么选4.1 包格式与发行版覆盖三架构都编译出来后分发方式又是一个需要仔细琢磨的问题。Linux 发行版各自为政deb 适用于 Debian、Ubuntu、Deepin、UOS 这些系统rpm 适用于 Fedora、RHEL、openEuler 这些系统tar.gz 是最后兜底方案。考虑到 PeaZip 用户里 Debian 系和 Ubuntu 系占比最大我把 deb 作为第一优先格式每个架构独立打一个包。发行版家族包格式安装方式Debian / Ubuntu / Deepin / UOSdebsudo dpkg -iFedora / openEuler / RHEL 系rpmsudo rpm -Uvh所有 Linuxtar.gz解压后直接运行目录内可执行文件所有 LinuxAppImagechmod x 后运行做 deb 包时控制文件里的Architecture字段要严格对应amd64 写amd64arm64 写arm64龙芯在 Debian 系规范里通常写loong64但有的仓库也接受loongarch64。如果这个字段写错dpkg 会直接拒绝安装提示架构不匹配。建议打好的包在每种架构的干净虚拟机里都试装一遍不要只看包管理器提示成功。4.2 文件命名、控制信息与校验文件名最好遵循发行版的命名习惯比如peazip_11.2.0-1_amd64.deb peazip_11.2.0-1_arm64.deb peazip_11.2.0-1_loong64.deb版本号里把上游版本和修订号分开后续修复依赖问题时可以直接递增修订号。控制文件里除了Architecture还要注意Depends字段。如果写的依赖过强比如强制要求某个具体版本的 GTK2用户系统上略微不同的版本就会导致安装失败如果依赖过弱缺少必要运行库用户装完又跑不起来。这需要你在两种风险之间找一个平衡点。最后每个包发布前必须对.deb和.rpm生成 SHA-256 校验和放在下载页面上省得用户下载时文件损坏还一头雾水。4.3 AppImage 的取舍如果目标是为不同发行版提供免安装体验AppImage 是个好选择。它的原理是把应用运行时需要的库都打包在一起用户下载后加个执行权限就能用听起来很美好实际做起来还是有几个地方要注意。第一AppImage 内的库版本如果跟宿主系统差异过大依然可能遇到 Glibc 版本冲突所以要在尽量老的兼容环境里制作。第二AppImage 的图标和桌面集成需要额外的 AppStream 元数据否则用户启动后看不到托盘图标。第三PeaZip 调用外部 7zz 引擎时引擎文件必须在 AppImage 的 mount 路径下可执行这就意味着制作工具要正确配置AppRun脚本处理好相对路径。建议仍然是先制作一个完整功能的 AppImage手动在 3 个架构的系统上跑一遍解压压缩流程再对外发布。5. 三架构实测对比与用户避坑指南5.1 功能与稳定性测试三套包出来后不能只看能不能打开界面。我的验证分三层第一层是基础功能创建 zip 和 7z 压缩包、解压 zip/7z/rar/tar.gz、设置密码、创建分卷、校验文件完整性全部过一遍第二层是异常场景比如压缩一个包含只读文件的目录、解压一个路径带中文的包、密码输入错误时的提示是否正常第三层是长时间运行稳定性我用一个 2GB 左右的目录做了连续 10 次压缩解压循环观察内存是否有明显泄漏。这个过程里发现 arm64 版本在连续循环解压大文件时偶尔会出现界面卡顿后来定位是线程池里对 7zz 进程的回调处理在高并发时锁竞争导致。这个和架构本身关系不大更像是通用逻辑问题之后在 amd64 上也能复现属于上游代码的一个 bug。这类问题对多架构适配者的启示是不能只测能跑不能跑还要测跑多久出问题性能和稳定性往往比单次功能更早暴露架构移植隐患。5.2 性能实测数据性能方面我用一个约 1.2GB 的混合目录包含大文件、小文件、文本、二进制做了压缩测试选用默认的 7z 压缩等级结果如下架构压缩耗时解压耗时CPU 占用备注amd64约 58 秒约 21 秒多核打满基线性能arm64RK3588约 96 秒约 35 秒多核打满能效比不错温度控制好loongarch64约 128 秒约 46 秒多核打满可用性没问题与架构代差相关这个数据仅供参考不同 CPU 型号差异很大。实际的意思是说PeaZip 在三个架构上都能正常完成核心任务性能差距主要体现在 CPU 本身的算力。至少在龙芯 3A5000 级别的设备上日常压缩解压是完全可用的不会再出现以前那种装不上、打不开、一跑就崩的情况。5.3 常见安装与使用问题最后集中说一下用户最容易踩的安装坑。第一个问题是下错架构包。arm64 和 amd64 的 deb 包表面看起来差不多但架构字段不同dpkg 会拒绝安装。如果安装时提示package architecture (arm64) does not match system (amd64)那就说明下错包直接换对应架构的下载链接不要试图加--force-architecture强制安装那样大概率跑起来直接段错误。第二个问题是提示缺依赖库。错误信息类似libgtk-x11-2.0.so.0: cannot open shared object file这在精简版系统上比较常见。解法是sudo apt install libgtk2.0-0对于 Ubuntu 24.04 等较新的系统GTK2 已经从主软件源移除了这时建议优先使用 AppImage 版本或者自己从旧仓库拉 GTK2 运行时。第三个问题是文件关联没生效。部分桌面环境需要用户到设置-默认应用里手动把压缩文件关联到 PeaZip或者运行 PeaZip 自带的设置关联功能。这是因为不同桌面环境对.desktop文件的 MimeType 处理方式不同不是安装包做错了只是需要一个手动确认步骤。还有一个很多人问的场景在苹果 M 系列芯片上跑 Linux 虚拟机比如用 QEMU 或 Parallels 装 Ubuntu这时虚拟机里的架构是 arm64不是 amd64下载 Windows 版或者 amd64 的 Linux 版都没有意义要下载 arm64 的 Linux 包。很多人在这一步反复出错以为Linux 包都一样实际上不同 CPU 架构的 Linux 包天差地别。最后一个建议在龙芯设备上安装完软件以后打开终端执行lscpu确认架构信息再下载。如果输出的 Architecture 是loongarch64或Loongson-3那就认准 loongarch64 构建不要碰 amd64 和 arm64 的包。这不是嫌麻烦是架构移植项目的底线规则。这次适配做完我最大的体会是跨架构工作里编译器只是起点真正的工程量在依赖库、打包规范、运行库兼容这些看不见的地方。PeaZip 11 能在三个架构上跑起来靠的也不是某一条神奇的命令而是把每个架构当成一个完整的产品来对待。后面如果再遇到类似的 Linux 桌面软件适配照这个思路走基本不会跑偏。