Yocto编译树莓派4镜像时两个库的do_compile任务长时间卡住如何解决

可能的核心原因 #

• 内存不足引发的进程阻塞/OOM：你的设备只有8G内存，Yocto默认会按照CPU线程数设置并行编译任务，8线程满载时编译gcc、glibc这类大组件会占满内存，触发频繁swap交换，看起来就像进度卡住，严重时编译进程会被系统静默杀死但bitbake无法感知，一直停留在该任务。
• 并行度配置超出硬件负载：默认的并行任务数没有考虑内存和磁盘性能上限，多任务同时读写会打满磁盘IO，尤其是使用机械硬盘时会出现长期无进度的情况。
• 构建依赖缺失：Ubuntu 20.04上缺少Yocto dunfell版本要求的依赖包时，部分编译任务会静默阻塞，无错误输出。
• sstate缓存损坏：之前的异常中断可能导致共享状态缓存损坏，重复构建时会卡在对应损坏的组件编译阶段。
• 层分支不匹配：三个依赖层如果分支没有严格对应dunfell版本，会出现依赖冲突、编译死锁问题。

排查步骤 #

• 确认卡住的具体任务：bitbake运行时按Ctrl + B后按f，查看当前运行任务的完整日志，定位到具体是哪两个包的do_compile阶段卡住；也可以打开构建目录下的tmp/work/<对应架构>/<包名>/<版本>/temp/log.do_compile查看实时日志输出。
• 监控系统资源：另开终端执行top和iostat 1命令，若内存占用持续超过90%且swap占用持续上涨，为内存不足；若磁盘IO使用率长期保持100%，为磁盘性能瓶颈。
• 验证依赖安装：执行sudo apt install gawk wget git-core diffstat unzip texinfo gcc-multilib build-essential chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev xterm补全所有构建依赖。
• 确认层分支一致性：检查poky、meta-openembedded、meta-raspberrypi三个层的当前分支都是dunfell，无跨分支混用情况。
• 清理损坏缓存：如果已经定位到卡住的包，执行bitbake -c cleanall <卡住的包名>清理对应缓存后重试。

优化解决建议 #

• 调整并行编译参数：在local.conf中添加以下配置，适配你的硬件配置：

# 并行bitbake任务数设为4，降低内存和IO压力
BB_NUMBER_THREADS = "4"
# 单make任务的并行线程数设为4
PARALLEL_MAKE = "-j 4"
# 限制每个线程至少占用2G内存，避免并行任务过多耗尽内存
BB_MEM_PER_THREAD = "2G"

• 扩容swap分区：创建至少16G的swap文件，避免内存耗尽直接杀死编译进程：

# 创建16G swap文件
sudo fallocate -l 16G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
# 如需开机自动挂载，可将"/swapfile none swap sw 0 0"写入/etc/fstab

• 磁盘优化：确保构建目录放在SSD上，若只能使用机械硬盘，将BB_NUMBER_THREADS进一步调整为2，减少IO竞争。
• 拆分编译流程：先单独编译大组件，再构建完整镜像，降低单次编译的资源占用：

bitbake gcc
bitbake glibc
bitbake core-image-minimal

内容的提问来源于stack exchange，提问作者Gökçe Demir