由于bbappend中的共享库符号链接，bitbake do_rootfs安装失败 [英] bitbake do_rootfs install fails with shared library symlink in bbappend

问题描述

我正在尝试从依赖于 libudev.so.0 但 openembedded-core 层的自定义配方中，将共享库包添加到Yocto Krogoth图像中 eudev 食谱仅提供 libudev.so.1.6.3 和 libudev.so.1 符号链接: libudev.so.1->libudev.so.1.6.3

I am trying to add a shared library package to a Yocto Krogoth image from a custom recipe that is dependent on libudev.so.0 but the openembedded-core layer's eudev recipe only provides libudev.so.1.6.3 and a libudev.so.1 symlink: libudev.so.1 -> libudev.so.1.6.3

我添加了一个创建符号链接的 eudev _％.bbappend recipes_core 配方

I have added a eudev_%.bbappend recipes_core recipe that creates the symlink

do_install_append() {
        ln -srf ${D}${base_libdir}/libudev.so.1 ${D}${base_libdir}/libudev.so.0
}

，我可以确认 libudev.so.0 文件已添加到

and I can confirm the libudev.so.0 file is added to the libudev package in

tmp/work/HOST/eudev/3.1.5-r0/image/lib/libudev.so.0 
tmp/work/HOST/eudev/3.1.5-r0/package/lib/libudev.so.0 
tmp/work/HOST/eudev/3.1.5-r0/packages-split/lib/libudev.so.0 
tmp/work/HOST/eudev/3.1.5-r0/sysroot-destdir/lib/libudev.so.0

并在构建映像时安装到映像的 tmp/sysroots/MACHINE/lib/libudev.so.0 目录中，并且出现在生成的 tmp/deploy/images/MACHINE/中IMAGENAME.tar.bz2 rootfs存档.问题在于，使用上述方法后，我无法将共享库程序包添加到映像，因为它会导致以下错误:

and installed to the image's tmp/sysroots/MACHINE/lib/libudev.so.0 directory when building the image and is present in the resultant tmp/deploy/images/MACHINE/IMAGENAME.tar.bz2 rootfs archive. The issue is that with the above in place I cannot add my shared library package to the image as it results in the following error:

do_rootfs: ...
Computing transaction...error: Can't install MYRECIPE@HOST: no package provides libudev.so.0

自定义配方确实设置了 RDEPENDS _ $ {PN} = libudev .

The custom recipe does have RDEPENDS_${PN} = libudev set.

为什么由于已安装的 libudev 软件包明显提供了 libudev.so.0 库而产生了 do_rootfs 错误?独立地对定制配方进行位烘焙没有问题，但是显然不会尝试将生成的程序包安装到映像中.

Why is the do_rootfs error generated as the installed libudev package clearly does provide the libudev.so.0 library? Bitbaking the custom recipe independently has no issue, but that obviously does not attempt to install the resultant package into an image.

推荐答案

为什么在安装的libudev软件包中生成了do_rootfs错误显然提供了libudev.so.0库吗?

Why is the do_rootfs error generated as the installed libudev package clearly does provide the libudev.so.0 library?

我很确定相关代码不是在查看文件名而是您的库所需的实际符号-打包魔术可以查看所有库和可执行文件，并根据它们的符号找出它们的运行时依赖关系需要(这是正确的依赖库最终出现在rootfs上的方式).我相信错误消息试图说没有可用的库导出您的库所需的符号.

I'm pretty sure the the relevant code isn't looking at file names but actual symbols needed by your library -- there's packaging magic that looks at all the libraries and executables and figures out their runtime dependencies based on the symbols they need (this is how the correct dependency libraries end up on the rootfs). I believe the error message is trying to say that no available library exports the symbols that your library needs.

您可以使用

readelf -a libudev.so.1 | grep SONAME
0x000000000000000e (SONAME)             Library soname: [libudev.so.1]

我尚未确认这是rootfs代码检查的内容，但很有可能.

I've not confirmed that this is what the rootfs code checks for but it's quite likely.

您是否希望与libudev.so.0链接的库仅与libudev.so.1一起使用，而无需重新编译?我不熟悉udev，但总的来说图书馆不太可能那样工作.

Are you expecting a library linked with libudev.so.0 to just work with libudev.so.1 without even a recompile? I'm not familiar with udev but in general libraries are unlikely to work like that.

自定义配方确实设置了RDEPENDS _ $ {PN} = libudev.

The custom recipe does have RDEPENDS_${PN} = libudev set.

通常不需要这样做-如果您的软件动态链接到库，则会自动找到运行时依赖项.

This is not normally needed -- if your software dynamically links to a library, the runtime dependency is found automatically.

这篇关于由于bbappend中的共享库符号链接，bitbake do_rootfs安装失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！