嵌入式Linux开发者Unix环境搭建避坑指南

　　半年前帮新来的嵌入式组搭Unix环境，现在想起来还手心冒汗——那台老式Dell工作站的风扇声比隔壁测试组的示波器还吵，键盘上还粘着前任留下的半块饼干渣。我原以为按文档走一遍流程就行，结果光安装交叉编译工具链就卡了三天，最后发现是某个依赖库的版本号被写死了，而文档里根本没提这茬。

　　先说最坑的包管理。你们肯定遇到过这种情况：用yum装gcc-arm-linux-gnueabi，结果提示依赖冲突；换apt-get，又卡在“无法满足的依赖关系”；最后咬着牙用源码编译，结果make到一半报错“undefined reference to __atomic_fetch_add_8”——这时候才想起要装libatomic1，可文档里只写了“安装必要依赖”，鬼知道这个“必要”到底包括啥？我后来直接在团队Wiki里写了条铁律：凡是涉及交叉编译的包，必须把完整依赖树打印出来贴在显示器上，否则等着被新人骂吧。

文章配图，仅供参考

　　我原以为只有新手会踩这些坑，结果有次和隔壁组的老王聊天，发现他们也遇到过类似问题。他说有次升级glibc，结果把系统自带的库给覆盖了，导致所有动态链接的程序都报错“invalid ELF header”。最后他们不得不用Live CD启动，手动把旧版glibc拷回来——那台机器的硬盘还是IDE接口的，拷个文件花了半小时，期间老王一直在念叨“这破机器早该换了”。

　　说到硬件，有次帮客户搭环境，他们用的是某国产ARM开发板，文档里写着“支持Ubuntu 18.04”，结果装完后发现网卡驱动不兼容。客户那边的工程师是个戴眼镜的小哥，说话带着点南方口音，他翻着文档说：“我们按说明装的，怎么就不行呢？”我拿过开发板一看——好家伙，文档里写的网卡型号是“RTL8111”，可实际板子上焊的是“RTL8125”，这两个型号的驱动能通用才有鬼了。最后我们不得不从源码编译驱动，编译时还报错“missing __sync_val_compare_and_swap_4”，原来是GCC版本太低不支持原子操作。那天下午外面下着大雨，机房里闷得像蒸笼，小哥的T恤后背全湿透了，可他还是坚持要自己改代码——后来我偷偷把空调温度调低了两度，他居然没发现。

　　现在回头看，这些坑其实都绕不开“优胜劣汰”的规律——能活下来的环境配置，都是被无数开发者用脚投票选出来的。比如我们组现在统一用CentOS 7，不是因为它多先进，而是因为它稳定，包管理没那么折腾，而且网上能找到的解决方案多。再比如交叉编译工具链，我们直接用Linaro的预编译版本，虽然体积大点，但至少不用自己解决依赖问题。至于那些花里胡哨的新发行版？等它们活过三年再说吧——我敢打包票，现在吹得天花乱坠的某个“轻量级”系统，三年后肯定没人记得它叫什么名字。

　　最后说个真事：有次帮客户修复环境，发现他们的/etc/profile里写了一行“export PATH=/usr/local/bin:$PATH”，而/usr/local/bin下有个自编译的gcc，版本比系统自带的低两级。结果他们编译内核时一直报错“incompatible pointer type”，查了半天才发现是编译器版本太旧。我问他们为什么不用系统自带的gcc，客户那边的负责人挠挠头说：“我们以为自己装的更好用……”那天我修完环境后，特意在他们的Wiki里加了条注释：“除非你清楚自己在做什么，否则别乱改系统路径——尤其是PATH。”

　　现在每次搭新环境，我都会先检查三件事：包管理器的版本、环境变量的配置、硬件的实际型号。至于文档？看看就行，别全信——毕竟写文档的人可能早就离职了，而坑还在那里等着你。对了，如果你们组也有类似的“环境配置血泪史”，欢迎来找我吐槽——我备着啤酒和花生，听你讲到天亮都行。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!