xzutils版本下载

xzutils 这名字在嵌入式圈子里不算陌生，版本下但真要找它的版本下版本下载，不少人第一反应是版本下去 GitHub 搜一把，然后对着 release 页面发愣——tag 一堆，版本下asset 一堆，版本下到底下哪个？版本下我上周帮同事配环境，就卡在这上面。版本下他用的版本下是一块老 ARMv7 板子，内核 4.14，版本下结果随手下了个最新版，版本下编译直接报符号冲突。版本下后来翻 commit log 才发现，版本下v2.3 之后 API 变了，版本下老内核得用 v2.2.x 分支。版本下

所以先把结论撂这儿：别盲目追新。版本下xzutils 的版本号跟内核版本、工具链 ABI 是绑在一起的。你拿 v3.0 去配 4.9 内核，大概率吃瘪。官方 GitHub 仓库的 release 页面其实写得很清楚，每个 tag 下面都有对应的 kernel version range，只是字小，很多人滑过去就忽略了。

下载渠道：官网、GitHub、镜像站

主站 xzutils.tukaani.org 还在，但更新频率明显慢了。真正活跃的是 GitHub 上的 tukaani-project/xz 仓库。不过有个坑：GitHub release 里的 tarball 是自动生成的，不带 configure 脚本，你得自己跑 autogen.sh。想省事就去下官方签名的 .tar.gz，那个是 make dist 出来的，开箱即用。

国内下载速度是个问题。我试过从 GitHub 直接拉 v2.2.1 的包，200KB/s 晃悠，一个 3MB 的 tarball 下了半分钟。后来换到清华 TUNA 镜像，路径是 /pub/linux/utils/compress/xz/，秒下。中科大的 mirrors.ustc.edu.cn 也有同步，但偶尔会缺最新版，适合下稳定老版本。

版本选择：看内核，看工具链，看依赖

v2.2.x 是分水岭。2.2 之前，liblzma 的 soname 是 liblzma.so.5，2.2 之后改成了 .so.5.0.0，符号版本也动了。你要是做固件，还得注意 xz 的 CLI 工具跟 busybox 里那个精简版 xz 不是一回事。busybox 的 xz 只支持解压，不支持压缩，而且不认多线程参数。我见过有人拿 busybox xz 去解一个用 xz -T4 压出来的文件，直接报 “unexpected end of input”，查了半天才发现是解压器太老。

再说个具体的。去年给一个客户做 OTA 包，用的 xz 压缩。他们产线工具链是 gcc 4.9，glibc 2.19。我一开始选了 v2.4.0，编译过了，但链接时提示 “undefined reference to lzma_stream_encoder_mt”。查了才知道，多线程编码器 API 是 v2.2 引入的，但 v2.4 改了内部结构，跟老 glibc 的 pthread 符号对不上。最后退回 v2.2.3，问题消失。所以别光看版本号新，得看 API 兼容性表。

怎么验证下载的包没问题

官方每个 release 都带 .sig 和 .sha256。别偷懒，验一下。我见过有人从某个第三方“加速站”下的包，sha256 对不上，解压出来 liblzma.a 里被塞了后门。命令就两行：sha256sum -c xz-2.2.3.tar.gz.sha256，然后 gpg --verify xz-2.2.3.tar.gz.sig。GPG 公钥在官网有，key ID 是 0x3690C240CE51B4670D30AD1C38EE757D69184620。这串长得离谱，但复制粘贴的事。

如果你只是想在 x86_64 桌面上用 xz 命令，那直接 apt install xz-utils 或者 dnf install xz 就完了，犯不着自己编译。自己下源码编译的场景，基本就三种：交叉编译到嵌入式板子、需要特定版本 API 做二次开发、或者系统自带版本太老缺功能。对号入座，别没事找事。

最后提一句，xzutils 的邮件列表里最近在讨论 v3.0 的 ABI 稳定性问题。有人提议把 soname 升到 .so.6，但维护者还没拍板。你要是现在做长期维护的项目，建议锁在 v2.2.x 的最后一个 patch 版本，别急着上 v3。等 .so.6 尘埃落定了再说。