4、手动收集依赖库：使用ldd + cp命令手动打包、编写Shell脚本自动化、处理符号链接问题

说实话，手动打包依赖库这件事，是我刚入行时最头疼的环节之一。那时候我天真地以为，把编译好的二进制扔到目标板上就能跑。结果呢？./my_app: error while loading shared libraries——这个错误，我相信每个做嵌入式Linux的人都见过。

嗯，今天我们就来彻底搞定它。

4.1 为什么需要手动收集依赖库？

你想想看，交叉编译出来的程序，在开发机上跑得欢，但一放到目标板就罢工。原因很简单：目标板的rootfs里没有这些动态库。

我个人的习惯是：能不静态编译就不静态编译。静态编译虽然省事，但体积大、更新麻烦。动态链接才是嵌入式Linux的常态。

所以，手动收集依赖库就成了必备技能。说白了，就是三步：

1. 找出程序依赖了哪些库
2. 把这些库从开发环境里拷贝出来
3. 放到目标rootfs的正确位置

4.2 使用ldd + cp手动打包

先来个最原始的方法。我刚开始就是这么干的，虽然笨，但能让你深刻理解依赖关系。

4.2.1 ldd命令的使用

ldd是Linux下查看动态库依赖的神器。用法很简单：

# 查看你的程序依赖哪些库
$ ldd my_app
    linux-vdso.so.1 (0x00007ffd8a3e0000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f8c1a200000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8c19e00000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f8c1a600000)

输出结果里，=>左边是库名，右边是库的实际路径。这就是我们要拷贝的目标。

4.2.2 手动拷贝的步骤

拿到依赖列表后，手动拷贝其实就几行命令：

# 创建目标目录
$ mkdir -p /path/to/rootfs/lib
$ mkdir -p /path/to/rootfs/usr/lib

# 手动拷贝每个库
$ cp /lib/x86_64-linux-gnu/libpthread.so.0 /path/to/rootfs/lib/
$ cp /lib/x86_64-linux-gnu/libc.so.6 /path/to/rootfs/lib/
$ cp /lib64/ld-linux-x86-64.so.2 /path/to/rootfs/lib/

嗯，这里要注意一个问题：符号链接。很多库文件本身是符号链接，指向真正的so文件。比如：

$ ls -l /lib/x86_64-linux-gnu/libc.so.6
lrwxrwxrwx 1 root root 12 Mar 15  2023 /lib/x86_64-linux-gnu/libc.so.6 -> libc-2.31.so

如果你直接用cp，默认会拷贝符号链接指向的真实文件。但有些场景下，你需要保留符号链接结构。这时候要用cp -d：

# -d 参数保留符号链接
$ cp -d /lib/x86_64-linux-gnu/libc.so.6 /path/to/rootfs/lib/
$ cp -d /lib/x86_64-linux-gnu/libpthread.so.0 /path/to/rootfs/lib/

4.3 编写Shell脚本自动化

手动拷贝一两个程序还行，但项目里动辄十几个二进制，每个依赖七八个库，手动搞就太累了。我后来写了个脚本，一劳永逸。

4.3.1 基础自动化脚本

这个脚本的核心思路：解析ldd输出，提取库路径，然后批量拷贝。

#!/bin/bash
# collect_libs.sh - 自动收集依赖库

TARGET_ROOTFS="/path/to/rootfs"
BINARY="$1"

if [ -z "$BINARY" ]; then
    echo "用法: $0 <二进制文件>"
    exit 1
fi

# 获取依赖库列表，过滤掉vdso和空行
LIBS=$(ldd "$BINARY" | grep -E "=> /" | awk '{print $3}')

for lib in $LIBS; do
    # 获取库的目录和文件名
    lib_dir=$(dirname "$lib")
    lib_name=$(basename "$lib")
    
    # 目标路径
    dest_dir="${TARGET_ROOTFS}${lib_dir}"
    
    # 创建目标目录
    mkdir -p "$dest_dir"
    
    # 拷贝库文件（保留符号链接）
    cp -d "$lib" "$dest_dir/"
    
    # 如果库是符号链接，还要拷贝真实文件
    if [ -L "$lib" ]; then
        real_file=$(readlink -f "$lib")
        cp -d "$real_file" "$dest_dir/"
    fi
    
    echo "已拷贝: $lib -> $dest_dir/"
done

echo "依赖库收集完成！"

这个脚本我用了好几年，基本够用。但有个问题：它只处理一级依赖。什么意思？就是你的程序依赖libA，libA又依赖libB，这个脚本只拷贝libA，不会自动处理libB的依赖。

4.3.2 递归依赖收集脚本

为了解决上面的问题，我写了个递归版本：

#!/bin/bash
# collect_libs_recursive.sh - 递归收集所有依赖库

TARGET_ROOTFS="/path/to/rootfs"
declare -A COPIED  # 记录已拷贝的库，避免重复

collect_deps() {
    local binary="$1"
    
    # 获取依赖库列表
    local libs=$(ldd "$binary" 2>/dev/null | grep -E "=> /" | awk '{print $3}')
    
    for lib in $libs; do
        # 如果已经拷贝过，跳过
        [ "${COPIED[$lib]}" = "1" ] && continue
        COPIED[$lib]=1
        
        lib_dir=$(dirname "$lib")
        lib_name=$(basename "$lib")
        dest_dir="${TARGET_ROOTFS}${lib_dir}"
        
        mkdir -p "$dest_dir"
        cp -d "$lib" "$dest_dir/"
        
        # 处理符号链接
        if [ -L "$lib" ]; then
            real_file=$(readlink -f "$lib")
            cp -d "$real_file" "$dest_dir/"
            COPIED[$real_file]=1
        fi
        
        echo "已拷贝: $lib"
        
        # 递归处理这个库的依赖
        collect_deps "$lib"
    done
}

# 从主程序开始递归收集
collect_deps "$1"
echo "递归依赖收集完成！"

4.4 处理符号链接问题

符号链接是手动打包里最容易踩坑的地方。我总结了几种常见场景：

场景	问题	解决方案
库文件是符号链接	只拷贝了链接，没拷贝真实文件	使用readlink -f获取真实路径，一并拷贝
多个符号链接指向同一个真实文件	重复拷贝，浪费空间	用关联数组去重，只拷贝一次
符号链接路径是相对路径	拷贝后链接失效	保持目录结构一致，或使用cp -d保留链接属性
ldd输出中的路径不存在	库文件被移动或删除	检查LD_LIBRARY_PATH和ldconfig缓存

嗯，这里有个我踩过的坑：相对路径的符号链接。比如：

$ ls -l /usr/lib/libfoo.so
lrwxrwxrwx 1 root root 16 Mar 15  2023 /usr/lib/libfoo.so -> ../lib/libfoo.so.1

这个链接指向的是/usr/lib/../lib/libfoo.so.1，也就是/lib/libfoo.so.1。如果你只拷贝了/usr/lib/libfoo.so和/lib/libfoo.so.1，但目标rootfs里/usr/lib和/lib的目录结构跟源系统不一样，这个链接就废了。

我的建议是：尽量保持目标rootfs的目录结构与源系统一致。或者，更激进一点——把所有库都放到同一个目录下，然后用ldconfig重建缓存。

4.5 验证打包结果

库都拷贝完了，怎么确认没问题？我一般做三步验证：

1. 检查文件完整性：用file命令确认拷贝的是ELF文件，不是空文件或损坏文件
2. 检查符号链接：用find -type l找出所有符号链接，逐个确认目标存在
3. 在目标板上测试：把rootfs烧录到目标板，运行程序，看是否报错

# 验证脚本示例
#!/bin/bash
# verify_rootfs.sh

ROOTFS="/path/to/rootfs"

echo "=== 检查符号链接 ==="
find "$ROOTFS" -type l -exec sh -c '
    target=$(readlink "$1")
    dir=$(dirname "$1")
    if [ ! -e "$dir/$target" ]; then
        echo "损坏的链接: $1 -> $target"
    fi
' _ {} \;

echo "=== 检查ELF文件 ==="
find "$ROOTFS" -name "*.so*" -exec file {} \; | grep -v "ELF" | head -5

echo "验证完成！"

说实话，手动收集依赖库这件事，看起来简单，但细节很多。我刚开始做的时候，经常漏掉某个库，或者符号链接没处理好，导致程序跑不起来。后来慢慢总结出这套流程，基本没再出过问题。

你想想看，掌握了这个方法，以后不管遇到什么程序，都能快速构建出可运行的rootfs。这才是嵌入式Linux工程师的硬功夫。