作用简述
将已编译的 Linux 可执行程序与某个 GLIBC 版本进行兼容
将已编译的 Linux 驱动程序强行适配某个内核版本
关于使用局限性及仓库地址见文章末尾
背景
早期在向低版本 glibc 环境部署工具链时，总是会遇到找不到高版本 glibc 符号的问题
于是就只能在低版本环境从源码构建出高版本 glibc ， 然后用
LD_LIBRARY_PATH、LD_PRELOAD指向它或者用patchelf工具批量修改二进制文件的rpath和新的动态链接器路径但这个方法太麻烦了，让我不由得产生一个疑问，既然报错的符号名称一致，为什么动态链接器非要匹配指定版本的符号？
既然它能知道 elf 文件所需的版本，那么这个版本肯定被记录在 elf 文件中了，那么能不能像修改文本文件一样，把版本调低呢？
CAdapt [ 2022 ]
于是就从网上找 elf 文件格式资料、相关源码
果珍，让我找到了一个很久以前别人用 c 实现的代码
然后就是编译验证，成功后就是古法分析、注解，然后改造了
由此，我的第一版CAdapt就诞生了
当然在后面使用过程中也暴露出一些问题，后续又进行了一些修复
UpModule （ 2025 ）
UpModule 的起因也很简单
就是因为后面做驱动开发时遇到了类似的问题
有时内核只是更新了一个小版本，原本正常的驱动就装载不上了
随后举一反三，既然以前做 CAdapt 可以直接修改已编译好的 elf 文件达到兼容的目的
那么同样修改已经编译好的驱动文件，是否也能达到此类目的呢
于是便尝试让 Ai 仿照着 CAdapt 的做法，输出一套用于内核模块硬兼容的代码
但不知道是 Ai 出于对于我这种行为的排斥，还是对内核代码并不了解，一直劝退我，导致最终未果
后面依旧是扒内核源码，分析内核模块装载时的校验逻辑，然后在代码中反向操作得以实现
Merge （ 26.10.02 ）
国庆节闲来无事，突然想到既然两者都属于同一类型的小工具，为何不合并成一个
后面再有类似需求再逐渐追加功能，慢慢发展成类似
patchelf那种的实用工具呢虽说现在 Ai 工具盛行导致工具廉价，但总能节省点 token 吧
于是使用 gemini 对两者进行了合并
Fix （ 26.10.12 ）
开始使用 codex ，刚好用这种小项目练习一下
于是便让他检查代码质量、以及有没有 bug
结果这世界上又多了个
回车战士……注意事项
说了这么多，讲讲局限性吧
对于 glibc 的适配：
● 要保证没有用到高版本 glibc 中特有的符号 ● 例如有些时间相关的……
● 要确定被修改的这个符号使用的一些数据结构没有发生改变，否则即使提示修改成功，实际运行也会崩溃 ● 比如某个结构体在低版本 glibc 中时 32 字节，高版本中变成了 64 字节，即便符号版本被降级成功，依旧 ABI 版本不兼容
以上两种情况对 kmod 也适用，同时对于启用了 CONFIG_MODVERSIONS 的内核模块，还需要获取目标内核导出符号对应的 CRC 信息
如果找不到对应的信息，就需要从系统中已安装的驱动中提取，如果提取到的符号覆盖了你驱动中使用的符号，那么就可以成功，反之失败
所以在编写驱动之初，就应该限制使用的函数数量以及更多的使用常用内核函数，这样的话再配合当前的工具就能在一定程度上提高驱动的兼容性
还有一点虽然不常见但也要注意，对于启用了强制模块签名校验的系统，修改后的模块还需要满足相应的签名要求。
仓库地址
CAdapt - GLIBC & KMOD 符号版本适配工具
UpModule - 原内核模块适配项目（已合并归档）