3、依赖关系基础：什么是软件依赖、静态链接与动态链接的区别、BusyBox的模块化依赖模型

各位同学，今天我们聊聊依赖关系。这个词听起来有点抽象，但说白了，就是「谁离不开谁」。你想想看，一个软件要跑起来，它可能需要别的库、别的工具、甚至别的配置文件。这就是依赖。

我在做嵌入式系统裁剪的时候，经常遇到一种情况：明明把 BusyBox 编译好了，烧到板子上，一运行就报错「找不到某某库」。嗯，这就是依赖没处理好。今天我们就把它彻底讲清楚。

什么是软件依赖

软件依赖，简单说就是：一个程序要正常运行，需要其他软件组件的支持。比如你的程序调用了 printf()，那它就需要 C 标准库。如果调用了 pthread_create()，那就需要线程库。

依赖分两种：

• 编译时依赖：编译程序时需要头文件、库文件。比如你编译 BusyBox 时需要 zlib.h。
• 运行时依赖：程序运行时需要动态库、配置文件、设备节点等。比如 BusyBox 的 mount 命令需要 /etc/fstab。

我记得有一次，我在裁剪一个路由器系统，把 libcrypt 去掉了，结果 login 程序死活登不上去。查了半天才发现，login 运行时需要 libcrypt.so 来做密码验证。这就是典型的运行时依赖没处理好。

静态链接与动态链接的区别

这个问题，面试经常问，实际工作中也经常踩坑。我直接说结论：

对比项	静态链接	动态链接
链接时机	编译时	运行时
生成文件	单个可执行文件（包含所有库代码）	可执行文件 + 多个 .so 文件
文件大小	较大	较小
部署复杂度	简单（一个文件搞定）	复杂（需要确保所有 .so 都存在）
更新库	需要重新编译整个程序	只需替换 .so 文件
内存占用	每个进程独立一份库代码	多个进程共享同一份库代码

静态链接的好处是「省心」。你把程序拷到任何一台 Linux 机器上，只要架构一样，就能跑。坏处是「浪费空间」——每个程序都包含一份 printf() 的代码，多几个程序就多几份。

动态链接的好处是「省空间」。所有程序共享一份 libc.so，内存和磁盘都省了。坏处是「依赖地狱」——你少了一个 .so，程序就罢工。我曾经在客户现场遇到过，一个嵌入式设备启动时找不到 libm.so.6，整个系统直接崩溃。嗯，从那以后我养成了一个习惯：裁剪系统时，先用 ldd 命令检查所有可执行文件的动态库依赖。

BusyBox的模块化依赖模型

BusyBox 的依赖模型，说白了就是「一个多功能的瑞士军刀，但每个功能之间可能有依赖关系」。它不像普通 Linux 系统那样每个命令是一个独立程序，而是所有命令都集成在一个二进制文件里。

BusyBox 的模块化依赖模型，我画了一张图，你看一眼就明白了：

从这张图你可以看到，BusyBox 的依赖模型是「星型结构」：

• 核心库 libbb：所有功能模块都依赖它。它提供了字符串处理、文件 I/O、内存管理等基础函数。
• 功能模块：每个命令（如 ls、cp、ps）是一个独立的模块，它们只依赖核心库，不依赖其他模块。
• 模块间依赖：极少。只有少数命令（如 mount 依赖 losetup）存在交叉依赖。

BusyBox 的依赖模型还有一个特点：配置时自动处理依赖。你在 make menuconfig 里选中某个命令，如果它依赖其他命令，系统会自动帮你勾上。但注意，这只是编译时的依赖检查，运行时依赖它不管。

举个例子：你选中了 login 命令，它会自动勾上 getty 和 passwd。但 login 运行时需要 /etc/passwd 文件，这个 BusyBox 可不会帮你生成。嗯，这就是我们后面要讲的内容——运行时依赖的处理。

总结一下

依赖关系是嵌入式系统裁剪的核心。你搞懂了静态链接和动态链接的区别，就明白了为什么有些库可以去掉，有些不能。你理解了 BusyBox 的模块化依赖模型，就知道裁剪时该从哪里下手。

我个人习惯是：先静态链接 BusyBox，再用 ldd 检查其他程序的动态库依赖，最后用 strace 验证运行时依赖。这套流程我用了很多年，基本没出过问题。

好，今天就到这里。记住一句话：依赖关系不是洪水猛兽，摸清了它的脾气，你就能驾驭它。