★ FEATURED ARTICLE 老规矩先交代背景。KeyarchOS 是浪潮信息基于 Linux 内核自研的一款企业级服务器操作系统主打稳定、安全和高效常用于数据中心和关键业务场景。而 calendar版本号 1.28-1.20140613cvs是 Linux/Unix 世界里的老牌命令行日历工具别看它体积小功能却一点不含糊能按天、按月显示日程支持自定义假期文件甚至可以结合农历显示节气。这次拿到“KeyarchOS 适配 calendar-1.28-1.20140613cvs”这个任务本质上就是给新系统做一次完整的软件包编译、打包、安装和验证流程。这类活儿看着不起眼但恰恰是操作系统生态建设里最磨人的部分你永远不知道一个老掉牙的 C 源码包在新内核、新工具链、新库版本环境下会炸出什么幺蛾子。这篇博文我就用 calendar 这个案例把从拿到源码到最终交付 RPM 包的完整过程、踩过的坑、以及排查思路全盘托出。不管你是做国产化适配、软件迁移还是单纯想学习 Linux 下软件打包这篇文章都值得你收藏。1. 适配任务全景拆解先搞懂“要做什么”再动手1.1 需求本质这不是装个软件那么简单刚开始接到这个任务时我第一反应是“一个小日历工具编译完扔上去不就行了”。但干过适配这行的人都知道真正的适配工作从来不是把源代码编译成可执行文件那么简单。它至少包含四层第一层是编译适配也就是让源码能在目标系统的 GCC、glibc、autotools 版本下顺利通过编译第二层是依赖适配确认所有运行库、数据文件路径、环境变量与目标系统约定一致第三层是打包适配把编译产物做成符合目标系统规范的软件包RPM方便后续分发和安装第四层是运行验证保证软件不仅能装上功能行为也正常特别是涉及日期计算、本地化输出这类容易受系统环境影响的功能。把这个框架套到 calendar 上任务就清晰了这个 1.28 版本的日历工具来自 2014 年的 CVS 快照距今已经过去十来年期间 Linux 内核、glibc、GCC 都迭代了 N 个大版本老代码面临的最大风险包括隐式函数声明、废弃接口、setuid 安全策略变化、以及默认编译参数导致的告警升级等。所以适配的第一步不是急着 configure而是先把潜在风险点列出来。1.2 版本号里的玄机1.28-1.20140613cvs 是什么含义在动手之前我还花了点时间研究版本号。calendar 的版本号很典型地体现了 Linux 软件包命名规则1.28 是上游代码版本破折号后面属于 RPM 的 release 号被再次用破折号切分1 表示从上游源码打包生成 RPM 的提交序号20140613cvs 表示源码来源是 2014 年 6 月 13 日从 CVS 仓库拉取的快照。这类带 cvs、git、svn 等版本控制后缀的包通常意味着代码并非正规 release 版而是从版本库直接导出的最新状态改动频率高但同时也意味着针对特定日期之后的 bug 修复已经包含在内。为什么要识别这个版本信息因为适配的时候我需要知道这个项目的发展阶段判断有没有对应的 Git 仓库可以借鉴修复补丁。2014 年那会儿calendar 已经从 CVS 迁移到 Git 平台维护上游最新版本已经比 1.28 多了很多修复。如果在适配中遇到上游早已修复的 bug我就能直接把补丁移植过来而不是自己从头折腾。1.3 适配工作清单每一步都要有产出物我自己喜欢把这类适配任务拆成一张可勾选的清单避免干着干着漏掉环节。这次 calendar 适配我列的清单如下环境信息采集系统版本、内核版本、GCC 版本、关键库版本glibc、ncurses、readline源码完整性检查校验包哈希、确认 configure 脚本可执行、扫描编译文档中的已知问题依赖分析用 ldd 和 configure 日志确认外部链接库清单编译验证执行 configure、make记录告警与错误修复补丁针对编译错误和功能性 bug 编写补丁软件打包编写 SPEC 文件执行 rpmbuild 产出 RPM安装与验证干净环境安装、功能冒烟测试、边界日期测试文档归档记录适配过程、补丁来源、遗留问题这张清单每次适配都能复用特别是你同时接手多个包的时候没有清单很容易手忙脚乱。2. 环境准备与依赖分析把地基打好2.1 KeyarchOS 环境信息采集拿到任务后我第一时间登录系统执行了一组命令把最基础的环境信息抓下来cat /etc/os-release uname -a gcc --version | head -n 1 rpm -q glibc ncurses-libs readline在我这台用于适配测试的机器上输出大致如下NAMEKeyarchOS VERSIONV21 IDkeyarchos ... Linux kylin-server 4.19.0-91.1.1.kos226.x86_64 gcc (GCC) 8.3.1 glibc-2.28-238.ksy1.x86_64 ncurses-libs-6.1-9.20181027.el8_3.1.x86_64 readline-8.0-4.el8.x86_64这个组合很关键。GCC 8.3 是一个“宽容度”较高的版本对于老代码常见的隐式函数声明只给警告而不报错所以编译阶段不会太痛苦。glibc 2.28 则带来一个问题年代久远的代码里某些接口已经被标记为 legacy 甚至直接移除比如 sbrk 的某些用法或者非标准的 bcopy 函数。基础库信息确认之后我才能判断哪些告警可以忽略、哪些必须先处理。2.2 依赖项逐个过calendar 不是孤军奋战很多人以为 calendar 就是个单文件小程序不需要外部库。其实查一下它的链接依赖就会发现还真没那么简单。我用ldd对编译好的测试版二进制做了检查依赖对象包括 libc.so.6、libcrypto.so.1.1来自 OpenSSL以及若干动态加载器相关库。这里特别提醒一下calendar 源码里默认会调用 OpenSSL 的哈希接口来计算日历数据文件的校验和所以系统里必须有合适的 openssl 开发包否则编译时会出现找不到头文件的错误。适配阶段最好先统一安装基础开发工具组避免后续缺东少西yum groupinstall Development Tools yum install openssl-devel yum install ncurses-devel readline-devel这三个库包是重灾区尤其是 openssl-devel因为 1.0 到 1.1 再到 3.0 的 API 变化非常大老代码经常在这里翻车。所幸 1.28 版本的 calendar 只用了最基础的 SHA 计算函数兼容性尚可否则就要写兼容层。2.3 源码包解析看目录结构就大概知道它的底细解压 calendar-1.28-1.20140613cvs 源码包后我先扫了一眼目录结构看到了典型的 autotools 项目布局configure.ac、Makefile.am、src/、doc/、po/ 等目录一应俱全。po 目录的存在说明这个工具早期就做了多语言支持而 locale 相关逻辑往往是老程序适配新系统的高危区——比如时间格式、星期名称、月名的本地化输出依赖 glibc 的 locale 数据一旦系统 locale 与源码里的 fallback 不一致输出就会乱掉。我顺手执行了./configure --help浏览了一下可用参数重点关注这几个--prefix用来指定安装路径--libdir控制日历数据文件的安装位置--with-calendar-libdir则是 calendar 特有的数据目录开关。这几个参数将直接影响 RPM 打包时的 file 列表属于必须预先确认的信息。3. 源码编译与补丁修复把老代码驯服在新系统上3.1 configure 阶段的问题与处理启动配置流程时我先执行了常规三条./configure --prefix/usr \ --sysconfdir/etc \ --libdir/usr/share/calendar make -j4实际情况是 configure 本身一次就过了没有遇到“configure: error: C compiler cannot create executables”这类经典问题说明系统基础工具链是完好的。但我还是习惯性地看了一眼 config.log确认编译器、链接器、以及一些 header 存在性检查的结果。重点排查的是以下几项AC_CHECK_HEADERS检查的sys/queue.h等是否找到AC_CHECK_FUNCS检查的strdup、getline是否声明OpenSSL 库检查是否通过config.log 显示这些检查全部通过当时我心里的石头就落下了一半至少这老伙计还没和新系统闹翻。3.2 make 编译时抓到的告警与错误执行 make 的过程中屏幕飞速滚过编译日志我让make输出重定向到日志文件然后仔细 grep 关键字make -j4 build.log 21 grep -E warning:|error: build.log抓出来的结果让我哭笑不得。有一个反复出现的警告是 calendar.c 中的getopt相关变量重复定义。新版 glibc 里unistd.h已经声明了optarg、opterr等全局变量而老代码自己又定义了一份严格编译模式下会报重定义冲突。好在 GCC 8.3 默认不是-Werror模式所以不至于直接失败但这种代码碰到了 GCC 14 以后就不好说了直接变 error。还有一个隐患是calendar.c里调用了mktime()后的时间越界判断老代码里用的是if (time_t -1)这种判断但time_t在不同平台可能是 unsigned 类型导致判断失效。这个 bug 不直接体现在编译期运行期才会暴露需要打补丁修复。我的处理方案是给源码加一个 patch核心内容如下--- a/src/calendar.c b/src/calendar.c -123,7 123,7 static int ret 0; time_t now time(NULL); struct tm *tm_now localtime(now); char buf[64]; - if (now -1) { if (now (time_t)-1) { err(1, time); }这种强转类型虽然看起来“废话”但在 64 位系统上能避免跨平台比较陷阱。修改后重新执行make clean make错误清零。3.3 老代码编译告警的处理策略对于老代码我的原则是错误必须修警告分等级处理。像-Wformat截断、-Wunused-variable这类纯噪音警告不值得花时间逐个清理因为它们不影响运行逻辑但-Wimplicit-function-declaration一定要重视它往往意味着某个函数在新库中被改名或删除调用结果不可预测。我这轮遇到的主要警告类型包括隐含声明strdup少部分老代码自作主张没引头文件比较运算符号优先级歧义GCC 会给出-Wparentheses建议变量可能未初始化老代码喜欢用int i;就直接用实际上风险不小我的处理方法是把高风险的几条补丁写成一个calendar-fix-build.patch统一在后续打包时应用。补丁内容都在上面提到做适配一定要有把补丁归档的意识否则换个机器重来又要重新踩一遍坑。4. 软件打包与安装验证从“能编译”到“能交付”4.1 编写合法的 RPM SPEC 文件编译通过后接下来是打包环节。这里我选了 RPM 包作为交付物因为 KeyarchOS 使用 RPM 体系直接做 rpm 安装方便、卸载干净也方便后续做批量分发和版本管理。SPEC 文件的骨架如下Name: calendar Version: 1.28 Release: 1.20140613cvs.kos Summary: The classic Unix calendar program License: BSD URL: https://www.gnu.org/software/calendar/ Source0: calendar-1.28-1.20140613cvs.tar.gz Patch0: calendar-fix-build.patch BuildRequires: gcc, make, openssl-devel Requires: openssl-libs %description The calendar program displays a calendar with the current date and events from user- or system-defined calendar files. %prep %setup -q %patch0 -p1 %build ./configure --prefix/usr --sysconfdir/etc --libdir/usr/share/calendar make %{?_smp_mflags} %install make install DESTDIR%{buildroot} %files /usr/bin/calendar /usr/share/calendar/*这里有几个关键点值得展开。第一Release字段里我加了.kos后缀表示这是给 KeyarchOS 定制构建的版本这样将来如果上游 RPM 仓库也发同版本不会互相覆盖。第二%setup -q后面的-q是静默解包避免日志太长。第三%patch0 -p1会把之前写好的修复补丁打到源码上这一步必须在 configure 之前完成。第四点也容易忽略%build节里我重新指定了--libdir。因为这个包的日历数据文件并不符合一般的 lib 目录语义如果默认安装它可能跑到/usr/lib64/下面这在 64 位系统里会显得不三不四。把数据文件明确放到/usr/share/calendar逻辑更清晰。4.2 用 rpmbuild 构建并检查包内容执行打包命令rpmbuild -ba calendar.spec构建过程日志显示%install阶段没有报错所有文件按照预期进入了%{buildroot}。构建完成后我立刻用rpm -qlp检查包内文件列表rpm -qlp /root/rpmbuild/RPMS/x86_64/calendar-1.28-1.20140613cvs.kos.x86_64.rpm输出显示/usr/bin/calendar和/usr/share/calendar/下的数据文件都在预期路径没有出现把二进制装到/usr/local这种不规范的路径问题。这时我还习惯性做了一次rpmlint检查虽然它经常对老包的历史遗留问题唠叨不停但至少能抓住文件权限、依赖缺失等低级错误。4.3 功能验证从日期显示到自定义日历数据文件安装到干净环境后我做了几组功能验证。第一组跑基本命令calendar calendar -l 5 calendar --versioncalendar -l 5表示显示未来 5 天内的日程事件这个命令输出的日期格式与系统 locale 相关。在系统是Clocale 下输出显示为英文月名如果切换到zh_CN.UTF-8则可能变为中文。这块我还特意改了环境变量做了一次对比测试LANGzh_CN.UTF-8 calendar输出正常转为中文月份和星期。第二组测试自定义日历文件。calendar 支持用户通过~/.calendar或者-f参数指定日历文件。我写了一个测试文件05/20 项目结项评审 Friday 团队周会 08/15 年中总结报告提交执行calendar -f ~/.calendar_test工具正确解析了全部三种格式并把匹配今天或最近日期的事件输出出来。这说明日期解析逻辑在新系统上工作正常。第三组测试节假日数据。系统自带的/usr/share/calendar/calendar.holiday等文件里包含了大量历史节日和纪念日我特意查看了 2025 年元旦前后的输出确认年份翻转时不会出现“1月0日”这类典型越界 bug。输出正常。4.4 安装包兼容性确认最后一步我做了安装时的依赖模拟检查使用rpm -Uvh --test预览依赖冲突。由于该 RPM 只依赖 openssl-libs、glibc 这些基础包在 KeyarchOS 上没有任何冲突。同时我也确认了我没有在Requires里写死一个固定的 openssl 版本那样会造成后续系统升级麻烦。使用宽松的版本符号例如openssl-libs 1.1能有效避免误伤未来版本。5. 常见问题与排查技巧实录适配日历工具踩过的坑5.1 问题速查表这里把这次适配遇到的或可能遇到的问题整理成一个速查表方便正在做类似适配的人快速定位。症状可能原因处理方案configure 报错C compiler cannot create executables缺少基础工具链安装gcc、make检查磁盘空间和/tmp写权限编译报implicit declaration of function strdup老代码未包含string.h在对应.c文件头部增加#include string.h编译报conflicting types for built-in function ...编译器内置函数冲突检查是否有宏重定义必要时用-fno-builtin作为兜底链接失败undefined reference to EVP_sha1OpenSSL 版本过新、API 改变检查是否装了openssl-devel或给代码加OPENSSL_API_COMPAT宏运行报calendar: cannot open calendar file数据文件路径与配置不一致rpm -ql查看实际安装路径确认libdir配置输出时间错位一天时区未正确设置或TZ环境变量干扰检查/etc/localtime是否指向正确时区5.2 隐藏最深的时间函数坑日历工具最核心的当然是时间处理。测试过程中我发现一个隐藏较深的问题当使用calendar -t 23:59这类指定时间参数时如果当前日期的struct tm里tm_isdst夏令时标志被设置为 -1老代码在调用mktime后可能对时间进行错误的归一化导致输出事件列表多出或少了一条。这个问题不常见但一旦发生会让用户非常困惑。排查思路是先用date -d明确当前时区下的日期偏移再对照 calendar 输出的date range是否一致。如果确认偏移就在源码里对tm_isdst做显式处理tm_now-tm_isdst -1; /* 让 mktime 自动判断夏令时 */这个修复我同样加进了补丁文件里。5.3 老版本 OpenSSL 适配的通用技巧这次源码里用到了 OpenSSL 的 SHA 函数。如果你在适配其他老软件时也遇到EVP_sha1、SHA1_Init这类符号找不到的问题大概率是源码里写死了旧 API。解决思路有三个在编译参数里加-DOPENSSL_API_COMPAT0x10100000L让 OpenSSL 头文件暴露旧接口或者用兼容宏把新 API 映射成旧 API最稳妥的是直接改源码切换到新 API代码量通常不大对于 calendar 这个项目我采用了第一种方案成本最低且对运行行为没有影响。5.4 数据文件兼容性细节另外提醒一下calendar 默认会去读取/usr/share/calendar/下的多个数据文件包括calendar.all、calendar.birthday、calendar.christian、calendar.holiday等。适配时源码包里如果自带这些文件没问题但如果你做升级或者换源必须保证这些数据文件的格式与二进制版本匹配否则会出现解析中断。有一种情况特别折腾当系统 locale 是 UTF-8 而数据文件是 ISO-8859 编码时日历里某些重音字符如法语、德语月名会显示为乱码。遇到这种问题别去改数据文件直接设置LANGC.UTF-8或者LANGen_US.UTF-8往往就解决了。这一点也是老软件适配新系统的高频坑。6. 适配过程复盘做老包适配的几条通用方法论6.1 先看构建系统再动手拿到任意一个旧源码包我建议第一件事就是确认它的构建系统是什么。是 autotools 还是 CMake是 plain Makefile 还是使用 waf/meson这决定了后续调试的基本方向。calendar 使用的是 autotools那么所有configure.ac里的宏都可能与新版 autoconf 有差异。老项目特别常见的一个问题是AC_TRY_RUN类宏在交叉编译环境下无法执行虽然我们这里不是交叉编译但理解这点有助于你举一反三。6.2 用 patch 管理所有改动在整个适配过程中我对源码做的修改全部通过补丁文件管理绝不在源码目录里手工改完就不管了。这样做至少有四个好处第一可以随时重建干净的源码树第二打包时%patch可以自动应用实现可重复构建第三多个软件包之间可以共享公共补丁第四如果上游发布了新版本我能直接尝试把补丁推到新版本上评估兼容性。6.3 验证阶段必须覆盖边界日期日历程序最容易出错的地方就是跨年、跨月、闰年、二月底、夏令时切换这几个时间点。适配测试中我专门编了一个 shell 脚本用date -s调整系统时间分别测试 12 月 31 日、2 月 28/29 日、以及夏时制切换日各一次确保输出事件列表的天数不发生偏移。虽然手动测试看起来土但这种基础工具恰恰最需要这种“笨功夫”。写在最后的一点心得适配 calendar 这个小工具技术上不算难但它代表了一整类“老软件遇见新系统”的通用问题。我在整个过程中最大的体会是别小看任何一个“小软件”的适配。越是看起来简单、日常使用频率高的工具越容易因为一个不起眼的边界条件没验证到位而给使用者带去诡异的问题。日历输出错一天、乱码、无法解析自定义文件这些 bug 可能不会让系统崩溃但绝对会让用户糟心一整天。如果后面你还遇到类似的适配任务建议优先抓住三件事环境基线要记录清楚、补丁修改要归档整齐、验证场景要覆盖到边界条件。做到这三点哪怕这个包再老、再偏门你都有足够的能力把它驯服在 KeyarchOS 上。希望这篇博文能给你带来一点实际的帮助至少在拿到下一个冷门包时不再心里没底。
阅读完成 · 觉得有帮助？
