使用bbappend中的共享库符号链接，bitbake do_rootfs安装失败

Question

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

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
}

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

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

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

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.

Answer 1

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

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.

You can check the soname your udev exports with

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

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

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.

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.