★ FEATURED ARTICLE 上个月往一组内网机器部署我自己编译的采集程序编译机是刚升级过的发行版目标机器普遍还停留在三年前的版本。scp 过去后直接执行终端立刻回了一行error while loading shared libraries: libssl.so.3: cannot open shared object file: No such file or directory。这类问题在 Linux 下太常见了——可执行文件本身不携带库它只带了一张 NEEDED 依赖清单真正干活的是加载器沿着清单找到的那些.so。这篇文章把我一直在用的依赖库打包脚本完整拆开怎么递归收集动态依赖哪些库即使看到了也绝对不能打包为什么$ORIGIN加 RPATH 重写能锁死加载路径以及打包之后怎么在干净环境里验证。目标读者是那些需要把编译产物分发到异构、离线或版本落后 Linux 环境的工程师看完可以直接把脚本抄走再根据自己的场景改成lib/子目录版或插件声明版。1. 缺库报错的本质动态链接器到底在找什么1.1 一行报错背后的加载流程当你在 shell 里执行./app内核并不直接运行你的代码。它会先解析 ELF 文件头从 PT_INTERP 段读到动态加载器的路径通常是/lib64/ld-linux-x86-64.so.2或基于 musl 的轻量发行版里的ld-musl-*.so.1由加载器接管后续启动过程。加载器拿到程序里 DT_NEEDED 记录的依赖清单对每一项按固定顺序去文件系统里搜索。搜索全部落空就产生你看到的那行报错error while loading shared libraries: libssl.so.3: cannot open shared object file: No such file or directory。这里要特别区分两个概念。程序记录的不是库文件路径而是 SONAME也就是库构建时定下的版本化名字比如libssl.so.3、libcrypto.so.3。开发机上/usr/lib/x86_64-linux-gnu/libssl.so.3存在目标机没有于是报错。同一个库在系统里可能同时存在多个版本号加载器只认 NEEDED 里写的那个名字不会自动帮你选一个“看起来差不多”的替代品。理解了这一点你就明白为什么“把二进制拷过去就能跑”只在目标机器恰好具备全部依赖时才成立。1.2 为什么用 ldd 判断依赖会骗人很多人习惯用ldd检查依赖。ldd本身不是解析 ELF 的静态工具它是把LD_TRACE_LOADED_OBJECTS1传给程序让真实的动态加载器去跑一遍加载流程。这意味着它有几个明显局限只对当前机器、当前环境有效。本机某个库在/usr/local/lib或某个软件自带的依赖目录里ldd显示正常换一台干净机器立刻歇菜。只适用于可执行且架构匹配的程序。交叉编译产物或者只读文件系统上的文件ldd会直接拒绝。有安全风险。它本质上会触发代码路径面对来路不明的二进制别拿ldd去测。我见过一个项目用LD_LIBRARY_PATH顶着跑了两周后来运维升级机器上的 Python全局脚本把那个环境变量覆盖掉全线崩溃。所以本地ldd正常不代表可以分发它只能证明“你当前这台机器上能跑”。真正的依赖收集必须脱离执行环境静态去读 ELF。1.3 真正可靠的依赖信息源收集依赖有三类信息源脚本里按顺序使用程序自身的 DT_NEEDED 列表用readelf -d或objdump -p静态读取。每个依赖库再递归出现的 DT_NEEDED逐层展开直到没有新库为止。库实体文件的位置用ldconfig -p的缓存索引外加/lib、/usr/lib、/usr/local/lib等默认目录兜底。readelf -d的输出长这样0x0000000000000001 (NEEDED) Shared library: [libssl.so.3] 0x0000000000000001 (NEEDED) Shared library: [libcrypto.so.3] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6]大多数机器默认装了 binutilsreadelf一定有。如果哪台精简机器上连这个都没有用objdump -p ./app | grep NEEDED效果一样。这两个工具都不执行目标代码拿到的是静态事实比ldd靠谱得多。2. 打包脚本递归收集、黑名单过滤、复制策略2.1 依赖收集不能只盯一层程序依赖libssl.so.3而libssl.so.3自己又依赖libcrypto.so.3libcrypto.so.3还依赖libz.so.1。如果你只把第一层 NEEDED 复制过去换到干净机器上加载器找到了libssl.so.3紧接着解析它的 NEEDED 时发现libcrypto.so.3不在照样报错。所以收集必须递归直到每个被复制的.so的所有 NEEDED 都解析完。脚本里我用一个COPIED关联数组做去重标记防止 A 依赖 B、B 又依赖 A 这种循环导致死循环。2.2 黑名单这些库看到也要放走递归收集的最大风险不是漏而是“多”。有些库拷过去不但没用还会把程序带崩。下面这个是必须留在目标系统的黑名单库名为什么不能打包ld-linux-x86-64.so.2、ld-linux-aarch64.so.1等加载器本身的路径由 PT_INTERP 写死在 ELF 里不经过 RPATH 搜索靠patchelf --set-interpreter硬改会引入 glibc 与内核接口错配得不偿失libc.so.6、libm.so.6、libpthread.so.0、libdl.so.2、librt.so.1、libresolve.so.2、libnsl.so.1、libnss_*glibc 与内核、NSS 机制深度绑定版本不匹配直接起不来具体见第 4 节linux-vdso.so.1内核虚拟映射出来的伪库根本没有实体文件libGL、libEGL、libdrm、显卡驱动相关库与具体 GPU 驱动和内核 DRM 绑定打包过去往往不是缺库而是错库崩溃方式更奇怪该带的是纯用户态第三方库libssl、libcrypto、libcurl、libz、libstdc、libgcc_s以及你自己项目编译出来的动态库。这类库和内核交互少版本兼容面宽带给目标机器基本没有副作用。判断标准一句话凡是需要和内核、硬件驱动打交道的留在系统凡是纯粹计算、协议、压缩类的用户态实现打包。2.3 递归与符号链接的细节库文件在系统里往往不是单文件比如libssl.so.3是一个真实文件同时还有libssl.so这个未版本化的开发链接。程序的 NEEDED 记录的是版本化 SONAME所以我们只需要复制版本化名字对应的那个文件。复制时最省心的做法是用cp -pL-L让源文件的符号链接被解开复制真实文件-p保留权限和时间戳。落到输出目录时文件名直接用 SONAME。这样加载器在$ORIGIN里按名字找必然命中。那些开发用的未版本化链接完全不用管运行时用不上。2.4 完整脚本下面这个脚本我一直在用逻辑上分六步建立ldconfig缓存索引、定义黑名单、提取 NEEDED、按 SONAME 找路径、递归复制、最后统一重写 RPATH。#!/usr/bin/env bash set -Eeuo pipefail # 用法: bundle_deps.sh 可执行文件 输出目录 BIN$(readlink -f $1) OUT${2%/} mkdir -p $OUT # ---------- 1. 建立 soname - 绝对路径 索引 ---------- declare -A LIB_CACHE while IFS read -r line; do [[ $line ** ]] || continue soname${line%% *} path${line##* } LIB_CACHE[$soname]$path done (ldconfig -p 2/dev/null || true) # ---------- 2. 系统基础库黑名单 ---------- SKIP_LIBS( linux-vdso.so.1 ld-linux-x86-64.so.2 ld-linux-aarch64.so.1 ld-linux-armhf.so.3 ld-linux-riscv64-lp64d.so.1 libc.so.6 libm.so.6 libpthread.so.0 libdl.so.2 librt.so.1 libresolv.so.2 libnsl.so.1 libutil.so.1 libnss_files.so.2 libnss_dns.so.2 ) is_skip() { local s for s in ${SKIP_LIBS[]}; do [[ $s $1 ]] return 0 done return 1 } # ---------- 3. 提取 DT_NEEDED ---------- needed_of() { readelf -d $1 2/dev/null | awk /\(NEEDED\)/ {print $NF} | tr -d [] } # ---------- 4. 按 soname 找路径 ---------- find_lib() { local soname$1 p d p${LIB_CACHE[$soname]:-} if [[ -n $p -e $p ]]; then echo $p return 0 fi for d in /lib /lib64 /usr/lib /usr/lib64 \ /usr/lib/x86_64-linux-gnu /usr/lib/aarch64-linux-gnu \ /usr/local/lib; do if [[ -e $d/$soname ]]; then echo $d/$soname return 0 fi done return 1 } # ---------- 5. 递归收集并复制 ---------- declare -A COPIED collect() { local f$1 soname npath real while read -r soname; do [[ -n $soname ]] || continue is_skip $soname continue if [[ -n ${COPIED[$soname]:-} ]]; then continue fi if ! npath$(find_lib $soname); then echo WARN: 找不到 $soname 2 continue fi cp -pL $npath $OUT/$soname COPIED[$soname]1 real$(readlink -f $npath) collect $real done (needed_of $f) } # ---------- 6. 复制主程序并收集 ---------- cp -L $BIN $OUT/$(basename $BIN) collect $BIN # ---------- 7. 重写 RPATH ---------- patchelf --force-rpath --set-rpath $ORIGIN $OUT/$(basename $BIN) for lib in $OUT/*.so*; do [[ -e $lib ]] || continue patchelf --force-rpath --set-rpath $ORIGIN $lib done echo 打包完成: $OUT ls -1 $OUT几个值得说明的设计点。set -Eeuo pipefail保证任何一个环节失败就立即退出不会生成半成品目录LIB_CACHE是从ldconfig -p输出里解析出来的省去了find全盘扫文件的漫长等待黑名单在复制前拦截搜到也不进循环这是安全底线。如果你的机器是多架构目录记得在find_lib的目录列表里补上对应的gnu路径。3. $ORIGIN 与 RPATH把搜索路径锁在本目录3.1 加载器的搜索顺序拷完库还差最后一步让程序优先加载自己旁边的库。同行的方法无非两种设置LD_LIBRARY_PATH或者改写 ELF 里的 RPATH/RUNPATH。前者我强烈不建议用于正式分发它是一个全局环境变量会被用户 shell 配置覆盖会在/proc/pid/environ里暴露路径setuid 程序还会无视它。正确做法是把路径写进 ELF让程序自带“寻址信息”。加载器的完整搜索顺序是这样的顺序机制关键特点1DT_RPATH旧式 RPATH对整个依赖闭包可见先于LD_LIBRARY_PATH若同一文件还有 DT_RUNPATH则被忽略2LD_LIBRARY_PATH环境变量全局影响setuid/setgid 程序会忽略3DT_RUNPATH新式 RUNPATH只对声明该属性那个对象自身的直接依赖生效不传递给子依赖4/etc/ld.so.cacheldconfig 生成的缓存系统包安装的库基本都在这里5/lib、/usr/lib等默认目录最终兜底这张表决定了后面很多坑。旧式 RPATH 优先级最高而且会传递到整个依赖树新式 RUNPATH 优先级反而在LD_LIBRARY_PATH之后并且不传递。写作本文时我特意用了“旧式”“新式”而不是“好的”“坏的”因为在新老之争里两个都有各自的适用场景。3.2 RUNPATH 的传递性问题只处理主程序是不够的假设目录结构是app/下有主程序和一组.so。如果只在主程序上设置RUNPATH$ORIGIN加载主程序时它确实能在app/里找到libssl.so.3。但接下来加载器要解析libssl.so.3自己的依赖libcrypto.so.3这时它不会回头看主程序的 RUNPATH而是看libssl.so.3自己有没有 RUNPATH。没有那就跳到/etc/ld.so.cache和系统目录。如果系统里恰好有一个旧版libcrypto轻则版本错重则符号缺失直接崩。这就是为什么处理 RUNPATH 时必须给每一个被复制的.so都打上同样的补丁一个都不能漏。旧式 RPATH 没有这个问题主程序的 RPATH 对整个依赖闭包生效子依赖的查找也会先走这个路径。很多便携包工具最终选择旧式 RPATH图的就是这条传递性。3.3 为什么我选 patchelf --force-rpathpatchelf --set-rpath默认会看目标文件原本用的是 RPATH 还是 RUNPATH跟随原标签行为不完全可控。我统一加--force-rpath强制写成旧式 DT_RPATHpatchelf --force-rpath --set-rpath $ORIGIN app patchelf --force-rpath --set-rpath $ORIGIN lib/*.so*注意$ORIGIN一定要用单引号包住防止被 shell 展开成空字符串。如果你按app/lib的结构放库主程序要写$ORIGIN/lib库之间则仍然用$ORIGIN因为它们彼此紧挨着。脚本里我偷懒把库和主程序放同一层所以统一用$ORIGIN就够了。patchelf会改动 ELF 的动态段这意味着程序包管理器的校验值会变化自己发的产品无所谓但要清楚这一点。改完可以用patchelf --print-rpath app复查。另外提醒一句用patchelf --set-interpreter改加载器路径属于另一步大手术那是把 glibc 程序往 musl 环境迁的玩法和依赖打包不要混在一起风险完全不是一个量级。4. glibc 是那道跨不过去的坎4.1 为什么拷 libc.so.6 是个危险动作很多人第一次写打包脚本时看到libc.so.6出现在 NEEDED 里顺手就想拷进去以为这样最保险。事实正相反。glibc 以符号版本机制对外暴露接口比如程序里引用GLIBC_2.34版本的pthread_create目标机器的 glibc 只有 2.31加载器在符号解析阶段就报version GLIBC_2.34 not found。这已经是“库存在但版本不够”的温和情况。如果硬把新机器上的libc.so.6拷到老机器问题会更难缠glibc 内部会调用内核的系统调用新版本可能依赖老内核没有的调用号加载器路径由 PT_INTERP 指定libc 又和加载器互相校验头信息版本对不上直接进入“不知道先有鸡还是先有蛋”的死锁状态。NSS 机制还牵扯到/etc/nsswitch.conf和libnss_*模块复制一个裸的libc.so.6根本覆盖不了整个体系。结论很明确glibc 是打包脚本的边界它必须由目标系统提供。你能做的是确认自己的程序对 glibc 版本的最低要求然后确保目标机器满足。4.2 打包前先量一下目标机器的 glibc在编译机上查程序需要的最低 glibc 版本objdump -T ./app | grep GLIBC_ | awk {print $NF} | sort -u | tail -5输出类似GLIBC_2.34这就是上限。在目标机器上执行getconf GNU_LIBC_VERSION如果目标是glibc 2.31而程序要求GLIBC_2.34那这个包在目标机上无论如何都跑不起来跟你的打包脚本没有关系。实际工程里的通行做法是用你要支持的最老版本 glibc 环境来编译比如在容器里装一个老基础系统的构建环境这样产物的版本要求天然向下兼容。这个原则比任何打包技巧都重要提前做能省掉后期一大半兼容性返工。4.3 实在要极致兼容就静态化如果你的目标是大量机器且没法控制 glibc 版本静态编译是更干脆的路。gcc -static能把绝大多数依赖并进可执行文件代价是 NSS 的 DNS、用户查询等机制仍然走系统静态 glibc 和动态 glibc 在少数行为上也有差异。C 程序可以退一步只用-static-libgcc -static-libstdc把两个最常出问题的 C 运行库并进去其余依赖继续动态打包负担小很多。想要真正脱离 glibc就换基于 musl 的静态编译链。musl 静态产物体积小、不依赖目标系统的 libc但你要接受它在 DNS 解析、locale、性能细节上和 glibc 的差异。这个属于另一个话题只是提醒你当依赖打包这条路越走越复杂时“干脆别依赖”往往才是最优解。5. 打包后的验证清单与两个隐藏坑5.1 验证一确认每个文件的 RPATH 都被改到打包完先做静态检查确认主程序和每个库的 RPATH 都是$ORIGINpatchelf --print-rpath ./app for f in ./*.so*; do echo $f: $(patchelf --print-rpath $f); done期望输出里只有$ORIGIN或按你目录结构调整后的$ORIGIN/lib。这步发现问题基本是脚本漏跑了对象修起来最快。5.2 验证二LD_DEBUGlibs 看真实加载路径静态检查过了还要确认运行时真的加载了包里的库而不是系统库。用 glibc 的调试输出跑一次env -u LD_LIBRARY_PATH LD_DEBUGlibs ./app 21 | grep -E trying file|search path | head -50env -u LD_LIBRARY_PATH是为了排除环境变量的干扰。看到trying file/path/to/bundle/libssl.so.3说明路径锁对了如果看到trying file/lib/.../libssl.so.3说明 RPATH 没生效回去查第 3 节。基于 musl 的发行版不支持LD_DEBUG可以用strace -e openat ./app 21 | grep \.so看实际 open 了哪些文件效果等价。5.3 验证三扔进一个最小纯净环境最接近真实部署的验证是把打包结果放进一个只有最小 rootfs 的容器或 chroot 环境里跑。基本步骤是创建一个空目录把打包产物复制进去再放一个静态编译的/bin/sh然后 chroot 进去执行mkdir -p rootfs/bin rootfs/app cp -r bundle/* rootfs/app/ # 放入静态 /bin/sh 到 rootfs/bin/sh chroot rootfs /bin/sh -c cd /app ./app这个环境里没有任何开发库、没有LD_LIBRARY_PATH跑通就说明依赖基本齐全。在 CI 里我习惯直接用最小基础镜像做同样的事每次发版自动跑一次比依赖人肉插 U 盘靠谱得多。5.4 两个容易忽略的边界dlopen 与 setuidreadelf -d只能看到编译期链接进 NEEDED 的库程序运行时用dlopen动态加载的插件根本不会出现在列表里。比如你的程序按规则去plugins/目录加载xxx.so这个xxx.so以及它自己的依赖都不会被脚本收集。解决办法是给脚本额外传入插件目录或者人工把插件塞进输出目录再对这个插件也跑一遍同样的readelf patchelf流程。排查时用strace -e openat ./app 21 | grep \.so | grep ENOENT一眼就能看出它尝试加载了哪些文件、因为缺什么而失败。另一个坑是 setuid。加载器在安全执行模式下会无视LD_LIBRARY_PATH新式 RUNPATH 通常也不被信任而旧式 RPATH 往往仍然生效。如果你要分发带chmod us的程序务必用--force-rpath写成旧式 RPATH并且在真实 setuid 条件下完整测试一遍不要想当然。我见过一个工具在普通用户下跑得正常提权后反而报库找不到排查到最后就是 RUNPATH 与安全执行模式的兼容问题。最后说一个我自己的习惯这个脚本我不会直接在编译机上跑而是放到 CI 里用一个故意装成目标环境最老基础库的构建容器来跑。这样打出来的包在多数机器上都能直接运行而且每次发版都会把sha256sum清单一起生成。哪天线上坏了先看清单确认文件有没有被意外替换再开LD_DEBUGlibs定位加载路径基本十分钟内能确定问题出在打包还是出在部署。别小看这个固定基础环境的动作——我踩过最多次的坑恰恰是编译机上某个依赖库被悄悄升了版本导致第二天打出来的包在全线上突然集体罢工。
阅读完成 · 觉得有帮助？
