使用Yocto生成rootfs遇异常：libc.so与libc.so.6为不同实体求助

我来帮你一步步理清这个问题，咱们从最关键的文件定位开始：

1. 先找出/usr/lib/libc.so属于哪个配方 #

Yocto自带的recipetool工具可以直接帮你定位文件所属的构建配方，运行下面的命令（把<rootfs_path>换成你实际生成的rootfs目录路径）：

recipetool find <rootfs_path>/usr/lib/libc.so

这个命令会输出生成该文件的配方名称，大概率是glibc-dev——因为libc.so（通常是链接脚本）是glibc开发包的一部分，而/lib/libc.so.6是glibc运行时的动态库本身，二者本来就是不同的实体，但目标rootfs里不应该包含-dev包，这才是导致SDK编译冲突的核心原因。

2. 检查为什么libc-dev会出现在目标rootfs里 #

你提到libc.so随libsqlite3-dev一同安装，那大概率是你不小心把libsqlite3-dev加入到了目标镜像的IMAGE_INSTALL变量中。libsqlite3-dev作为开发包，会依赖glibc-dev，而glibc-dev会把/usr/lib/libc.so安装到rootfs里。

验证这一点的话，可以查看你的镜像配方（比如core-image-minimal.bb或者自定义的镜像bb文件），检查IMAGE_INSTALL里是否包含libsqlite3-dev——正常情况下，目标rootfs只需要安装libsqlite3（运行时库）即可，-dev包是给SDK开发用的，不应该出现在目标镜像里。

3. 修复方案 #

• 从IMAGE_INSTALL中移除libsqlite3-dev，只保留libsqlite3；
• 重新构建rootfs，确认/usr/lib/libc.so不再出现在目标镜像中；
• 如果你需要在SDK中编译依赖sqlite3的程序，只需要确保SDK包含libsqlite3-dev即可（Yocto构建SDK时会自动处理开发包依赖，不需要在目标rootfs中预装）。

额外排查点 #

如果上面的步骤没找到问题，你可以做进一步检查：

• 找到glibc的配方文件（通常在meta/recipes-core/glibc/glibc_<version>.bb），查看FILES变量和do_install函数，确认是否有错误地将libc.so安装到目标rootfs的逻辑；
• 运行bitbake -g libsqlite3-dev && cat pn-buildlist | grep glibc，查看libsqlite3-dev的依赖链，确认是否有其他间接依赖引入了glibc-dev。

内容的提问来源于stack exchange，提问作者Jade