1. 先说清楚zlib-devel 到底是什么为什么非装不可1.1 一个安装失败引发的连锁反应前阵子在一台麒麟 V10Kylin V10x86_64 服务器上部署环境先是给 Python 3 源码编译做准备后来又编译 Nginx结果几乎在同一个地方卡住configure阶段报错提示zlib.h: No such file or directory或者干脆告诉你zlib library not found。第一次遇到这个报错的人大概率会下意识去执行yum install zlib结果装上之后再次编译问题依旧。这不是玄学而是你只装了运行库没装开发包。zlib 是绝大多数 Linux 系统都会内置的压缩库负责 DEFLATE 压缩算法系统里跑着的很多程序都在用它。但你要编译源码、要开发调试光有运行库还不够还需要头文件、静态库、pkg-config配置信息这些东西全部收在zlib-devel里。这篇笔记就是来复盘这个安装过程的。标题里那个版本号1.2.11-20.ky10.x86_64看着挺长其实拆开很好懂1.2.11是 zlib 版本20是麒麟系统的打包版本号ky10表示这个包专门为麒麟 V10 构建x86_64是 CPU 架构。我尽量把安装步骤、源配置、常见报错的排查思路都写清楚既能满足第一次上手麒麟系统的新手直接抄作业也能给已经踩过坑的人一个可以对照的速查手册。1.2 zlib 和 zlib-devel差在哪这里要先说清楚两个包的关系因为每次有人问“为什么我明明装了 zlib编译还是找不到”答案都在这。zlib 主包提供的是动态库文件/usr/lib64/libz.so.1以及对应的运行时组件。程序在运行的时候需要加载这个动态库所以叫“运行库”。zlib-devel 提供的是头文件/usr/include/zlib.h以及相关的zconf.h开发链接用的软链接/usr/lib64/libz.so它一般指向libz.so.1.2.11这种带完整版本号的库文件静态库/usr/lib64/libz.apkg-config的zlib.pc文件方便各种构建脚本自动探测 zlib 的编译参数。编译阶段的时候编译器需要读取头文件确认函数签名和宏定义链接器需要通过libz.so软链接找到动态库。所以只装 zlib 不装 zlib-devel等于你拿到了一把锁但没给钥匙锁能看见门打不开。1.3 麒麟 V10 的包管理体系和 CentOS 的关系麒麟 V10 有服务器版和桌面版之分两者的软件仓库体系略有差异但底层都是基于 RPM 包管理继承了 CentOS/RHEL 那一套 yum/dnf 工具链。因此很多在 CentOS 上能用的命令、软件源配置思路在麒麟上同样适用只是仓库的地址和包的命名会带ky10或ks10这样的麒麟专属标记。这意味着你在网上下载一个zlib-devel的 rpm 包时不能随便拿 CentOS 的版本乱装最好选择*ky10*.x86_64.rpm这种带麒麟标识的包或者直接从麒麟的官方仓库安装。混装 CentOS 的包有时候能跑但依赖关系一旦对不上后面会出现很多莫名其妙的问题。如果你手头是 aarch64ARM64架构的麒麟机器包名会变成zlib-devel-1.2.11-20.ky10.aarch64.rpm别下错成 x86_64 的架构不对rpm 会直接拒绝安装。2. 安装前的环境检查与软件源准备2.1 先摸清自己的系统版本和架构很多人在安装前不看系统信息直接复制网上的命令跑结果装不上或者装错包。开始动手前先花一分钟确认三件事系统版本、发行版标识、CPU 架构。cat /etc/os-release uname -m执行之后你会看到类似这样的输出NAMEKylin Linux Advanced Server VERSIONV10 (SP3) IDkylin VERSION_IDV10 PRETTY_NAMEKylin Linux Advanced Server V10 (SP3)uname -m输出x86_64说明是 64 位 Intel/AMD 架构。如果输出的是aarch64那就是 ARM 架构后面的包选择要注意切换。这一步的意义在于确认你是“服务器版”还是“桌面版”。桌面版在安装开发工具链时常常出现源里找不到包的情况服务器版的仓库相对完整一些。如果你在桌面版上发现yum install zlib-devel找不到包可以看看是不是仓库标识符的问题后面我会专门讲。2.2 检查 yum 源状态确保仓库可用麒麟 V10 安装完系统后/etc/yum.repos.d/目录下一般会有麒麟自带的 repo 文件比如kylin_x86_64.repo或者类似命名的文件。安装任何软件之前建议先跑一遍仓库检查确认 yum 能正常连通远端仓库yum repolist正常情况下会列出一到两个启用的软件仓库并能拉到包元数据信息。如果执行后长时间卡住或者提示Cannot retrieve repository metadata、cannot find a valid baseurl for repo这类的错误那说明源有问题先解决源的问题再谈安装 zlib-devel。另外用户还经常遇到这种情况机器上除了麒麟自带的源还残留了之前配置的 CentOS 或第三方仓库文件比如CentOS-SCLo-scl.repo、CentOS-Base.repo这类文件放到麒麟系统上。这些 repo 文件里的baseurl指向的是 CentOS 的镜像地址在麒麟系统上很可能解析失败这时候 yum 执行任何操作都会抛出一堆“找不到有效 baseurl”的报错。排查思路很简单进入/etc/yum.repos.d/目录逐个查看 repo 文件把不属于麒麟的源禁用或者移走。cd /etc/yum.repos.d/ ls -la # 把不需要的 repo 文件改后缀名禁用比如 mv CentOS-Base.repo CentOS-Base.repo.bak只保留麒麟自己的源之后再执行yum clean all yum makecache yum repolist仓库恢复可用后后面安装包的过程会顺利得多。2.3 如果系统默认源不好用可以换阿里云镜像麒麟官方源有时候因为网络环境原因访问很慢或者干脆解析不了域名。这时候我比较推荐换成国内公共镜像源实测下来阿里云的麒麟源稳定性和速度都不错。在修改之前先把原始 repo 文件备份好。假设原始文件是kylin_x86_64.repocp /etc/yum.repos.d/kylin_x86_64.repo /etc/yum.repos.d/kylin_x86_64.repo.bak vi /etc/yum.repos.d/kylin_x86_64.repo然后参考下面的格式修改注意baseurl的路径要跟你的系统版本对应[kylin_x86_64] nameKylin Linux Advanced Server - x86_64 baseurlhttps://mirrors.aliyun.com/kylin/KYLIN-V10-SP1-2305/x86_64/ enabled1 gpgcheck0改完之后同样执行yum clean all yum makecache重建缓存。需要留意的是麒麟系统每个小版本的路径名略有差异比如 SP1、SP2、SP3 的路径可能都不一样如果发现 404 就打不开镜像目录首页根据实际版本自己调整一下路径即可。3. 安装 zlib-devel 的三种实操方法3.1 方法一直接 yum 在线安装推荐新手在源配置没问题的情况下安装 zlib-devel 最简单的方式就是yum install -y zlib-devel如果想先看看 yum 会安装哪些依赖包可以先不带-y参数yum install zlib-develyum 会解析依赖关系一般会提示需要同时安装或更新zlib、zlib-devel这两个包确认无误后输入y继续。我实际执行时看到的输出大致是这个样子Dependencies resolved. Package Architecture Version Repository Size Installing: zlib-devel x86_64 1.2.11-20.ky10 kylin_x86_64 118 k Installing dependencies: zlib x86_64 1.2.11-20.ky10 kylin_x86_64 98 k Transaction Summary Install 2 Packages这时候你会看到它自动安装了zlib-1.2.11-20.ky10.x86_64因为zlib-devel的依赖要求运行库也必须是对应版本。这个版本就是麒麟 V10 仓库里官方打包的不需要去网上乱找。安装完成后可以通过rpm -qa | grep zlib验证。用 yum 在线安装的最大好处是依赖关系由系统自动处理不需要自己一个个 rpm 包手动敲。如果你刚接触 Linux优先用这种方式省心。3.2 方法二rpm 离线包安装适用内网环境很多生产服务器是没有外网权限的这时候就得走离线安装路线。先在有网络的环境下把zlib-devel和它的依赖都下载好然后拷贝到目标机器上安装。在有网机器上执行yumdownloader --resolve zlib-devel --destdir/tmp/zlib-rpms这条命令会把zlib-devel以及所有依赖包一并下载到/tmp/zlib-rpms目录。如果没有yumdownloader命令可以安装yum-utilsyum install -y yum-utils下载完成后把/tmp/zlib-rpms整个目录拷贝到目标机器上然后在目标机器进入该目录执行rpm -ivh zlib-devel-1.2.11-20.ky10.x86_64.rpm如果提示依赖缺失比如缺少对应版本的zlib就先把依赖的 rpm 包也装了。手头有多个 rpm 包时也可以一次性全部安装rpm -ivh *.rpm或者更省事一点用 yum 本地安装让系统自动处理依赖yum localinstall -y *.rpmlocalinstall的好处是它会扫描当前目录下的 rpm 包把依赖一起装上。离线安装最关键的一点是版本匹配。目标机器上原来的 zlib 版本如果跟zlib-devel要求的不一致比如你已经手动升级过 zlib 到 1.2.13那么装1.2.11的 zlib-devel 极可能报依赖冲突。这种时候要么卸载现有的 zlib要么找一个跟现有 zlib 版本配套的 zlib-devel 包。3.3 方法三源码编译安装不推荐但讲清楚原理网上有一些教程会让你去 zlib 官网下载源码包然后手动 configure、make、make install。这个方法理论上有一定灵活性可以自定义安装路径但在系统级环境里我强烈不建议你这么做。原因有三个系统原本的 zlib 是 RPM 管理的你再用源码装一套可能把/usr/lib64/libz.so覆盖掉导致整个系统的库版本跟包管理器记录的元数据不一致之后 yum 更新、升级都会出问题zlib 是底层基础库Python、OpenSSH、Nginx 等大量软件都在链接它一旦版本错位编译出来的程序可能运行时找不到库源码安装的 zlib 不会产生 RPM 元数据以后卸载、升级都会留下隐患。如果只是临时需要某个特定版本去编译某个软件正确做法是把源码编译的 zlib 安装到一个独立前缀目录比如/usr/local/zlib然后编译其他软件时通过CPPFLAGS和LDFLAGS指定路径去引用而不是动系统的/usr目录。具体操作大概是wget https://www.zlib.net/zlib-1.2.11.tar.gz tar xf zlib-1.2.11.tar.gz cd zlib-1.2.11 ./configure --prefix/usr/local/zlib make -j$(nproc) make install然后在编译其他软件时加参数export CPPFLAGS-I/usr/local/zlib/include export LDFLAGS-L/usr/local/zlib/lib这样可以让特定软件用到你指定的 zlib系统自带的 zlib 不受影响。但这种方案维护成本高能不用就不用。4. 验证安装结果与常见问题排查4.1 怎样确认 zlib-devel 真的装好了安装完成后有几种验证方式建议按顺序执行一遍。rpm -qa | grep zlib正常会看到类似输出zlib-1.2.11-20.ky10.x86_64 zlib-devel-1.2.11-20.ky10.x86_64确认包已经存在之后进一步看关键文件是否到位ls -l /usr/include/zlib.h ls -l /usr/include/zconf.h ls -l /usr/lib64/libz.so这三个文件只要存在编译环境基本就齐了。还可以用rpm -ql查看这个包安装了哪些文件rpm -ql zlib-devel输出列表里你会看到头文件、静态库、pkg-config 文件等。也可以用 pkg-config 验证pkg-config --modversion zlib能正常输出版本号1.2.11说明 pkg-config 的路径配置正确。再进一步写一个几行的 C 程序测试编译链接这是最直观的验证。新建一个zlib_test.c#include zlib.h #include stdio.h int main() { printf(zlib version: %s\n, zlibVersion()); return 0; }然后编译gcc zlib_test.c -lz -o zlib_test ./zlib_test如果输出zlib version: 1.2.11说明头文件、链接库、运行库全部正常系统里已经具备了使用 zlib 开发编译的能力。4.2 编译其他软件时找不到 zlib 的常见报错安装完 zlib-devel 之后最常见的坑反而不是装不上而是编译软件时仍然报错。这里列几个我实际遇到过的版本报错一zlib.h: No such file or directory这个说明头文件路径没找对。正常情况下/usr/include/zlib.h存在的话gcc 默认查找路径就能找到。如果软件 configure 脚本指定了非标准路径或者你手动加了CPPFLAGS把路径指到了别处就可能出现这种情况。排查时先确认头文件确实存在然后检查是否加了多余的-I参数。报错二undefined reference to inflate或者undefined reference to deflate这是链接阶段的问题说明编译时缺少-lz链接参数。比如你用 gcc 编译gcc test.c -lz -o test注意-lz要放在源文件之后。如果 configure 脚本已经找到了 zlib 但还是报这个错可以手动指定LDFLAGS-lz ./configure报错三configure 检测提示zlib library not found这种情况通常是 configure 脚本通过 pkg-config 查找 zlib而 pkg-config 的.pc文件路径有问题。确认一下/usr/lib64/pkgconfig/zlib.pc是否存在如果存在但 pkg-config 搜索不到可以设置环境变量export PKG_CONFIG_PATH/usr/lib64/pkgconfig这三个报错覆盖了大部分编译场景核心思路就是确认头文件存在、确认链接库存在、确认 pkg-config 能找到。4.3 “cannot find a valid baseurl for repo” 的速查表这个报错出场率实在太高了特别是刚接触麒麟系统、或者从 CentOS 迁移过来的人很容易被它卡住。它本身跟 zlib-devel 安装没有直接关系但如果你不把这个问题解决yum 什么包装不了。错误现象可能原因解决方法cannot find a valid baseurl for repo: base/7/x86_64/etc/yum.repos.d/中残留 CentOS 的 repo 文件禁用或删除非麒麟的 repo 文件只保留麒麟源cannot find a valid baseurl for repo: centos-sclo-rh/x86_64配置了 SCL 第三方源麒麟仓库里没有对应路径将对应.repo文件改名为.bak禁用执行yum makecache长时间卡住源地址不可达或 DNS 解析慢检查baseurl能否访问更换镜像源$releasever变量解析为空repo 文件里用了变量但系统版本识别异常手动把$releasever替换成实际版本号如V10安装时报 GPG 签名错误源路径不对或缺少 GPG key临时加--nogpgcheck或者导入对应公钥如果不想手动逐个试最稳妥的路径就是清空/etc/yum.repos.d/中所有非麒麟 repo 文件使用麒麟官方源或阿里云镜像源然后yum clean all yum makecache。做完这些这个报错基本能解决 90% 以上。4.4 架构与版本混搭的坑zlib-devel 的安装包里架构是一个不容忽视的维度。x86_64 机器上装 i686 的包rpm 会直接报wrong architecture。反过来aarch64 机器上装 x86_64 的包也不行。所以下载离线包时务必先看uname -m的输出。另外麒麟 V10 的仓库里有时会同时存在zlib-1.2.11-20.ky10.x86_64和zlib-1.2.11-19.ky10.x86_64这种相邻版本。如果你系统里已经装了旧一点的版本直接rpm -ivh新版本可能出现冲突这时候用rpm -Uvh升级安装或者用yum install让依赖管理器自动处理更安全。还要注意一点尽量不要手动卸载系统自带的旧 zlib直接强制卸载底层的zlib很可能导致 yum、rpm 本身依赖受损因为这两个工具自身的运行也要用到 zlib 库。万一真出现这种问题恢复起来相当麻烦。5. 装完 zlib-devel 之后有哪些常用后续操作5.1 用它给 Python 源码编译扫清障碍说到装 zlib-devel 的动机很多人是为了编译安装 Python。Python 源码编译时如果检测不到 zlib 开发环境即使 Python 本身能编译出来后续pip装带压缩功能的包也会出问题甚至ensurepip模块都可能报错。我通常这样操作yum install -y zlib-devel openssl-devel libffi-devel readline-devel tar xf Python-3.9.18.tgz cd Python-3.9.18 ./configure --prefix/usr/local/python3 --enable-optimizations make -j$(nproc) make install编译配置阶段configure 脚本会自动找到/usr/lib64/libz.so和/usr/include/zlib.h进而启用 zlib 模块。安装完成后可以验证/usr/local/python3/bin/python3 -c import zlib; print(zlib.ZLIB_VERSION)能正常输出1.2.11说明 Python 的 zlib 支持已经可用。5.2 给 Nginx 编译提供压缩库支持Nginx 的 gzip 模块、HTTP 压缩传输都依赖 zlib。源码编译 Nginx 时如果系统缺 zlib-develconfigure 阶段会直接报错。装好 zlib-devel 之后编译命令可以这样写yum install -y pcre-devel openssl-devel zlib-devel tar xf nginx-1.24.0.tar.gz cd nginx-1.24.0 ./configure --prefix/usr/local/nginx --with-http_ssl_module --with-http_gzip_static_module make -j$(nproc) make install默认情况下Nginx 的 configure 脚本会自动检测 zlib不需要手动指定--with-zlib路径。只有在你把 zlib 编译到了非标准路径时才需要手动加参数./configure --with-zlib/usr/local/zlib不过大多数场景下系统级 zlib-devel 就够用了。5.3 用 yumdownloader 一次性打包离线工具集如果你需要在一个没有外网的内网环境里批量部署多台机器手动传 rpm 包效率太低。我习惯在有网的一台同配置机器上把所有依赖一次性拉下来然后拷到内网统一安装。比如要同时装 zlib-devel、openssl-devel、pcre-develcd /tmp yumdownloader --resolve zlib-devel openssl-devel pcre-devel --destdir/tmp/rpms然后把/tmp/rpms下的所有 rpm 包拷到内网机器上rpm -ivh /tmp/rpms/*.rpm或者用createrepo把这些包做成一个本地仓库配置一个本地 repo 文件之后就能用 yum 正常安装这些包了。内网机器多的情况下这种方式比一个个 rpm 手动敲要省太多事。5.4 最后的几个实操心得我在这些操作上反复踩过坑总结几条个人经验第一尽量用 yum 安装系统级库不要手动编译安装覆盖/usr/lib64/下的库文件。编译源码这种事留给那些需要定制版本或者非标准路径的场景。第二配置好软件源之后第一时间做yum makecache并且在装开发包之前先yum repolist确认仓库状态。很多时候问题不是出在包本身而是源不可用。第三离线安装时一定要确认 rpm 包的系统标识和架构。ky10的包装到非麒麟系统上可能出现运行时不兼容的问题x86_64 的包装到 aarch64 机器上则直接无法安装。第四如果你需要的是 32 位版本的 zlib-devel命令要写成yum install zlib-devel.i686默认装的永远是当前系统架构对应的包。不过现在纯 32 位应用场景越来越少了了解即可。麒麟 V10 作为一个国产 Linux 发行版整体还是沿用了 RPM 体系的操作习惯。只要把源搞清楚、版本对应上装开发包其实跟在 CentOS 上没有本质区别。以后遇到类似的基础库缺失问题比如 openssl-devel、readline-devel、libffi-devel都可以套用同样的排查思路先确认系统架构和版本再检查软件源可用性然后 yum 安装对应包名的-devel版本最后用 pkg-config 或写段小代码验证编译环境。这套方法在麒麟系统上跑通之后其他基础依赖的安装也会顺手很多。