96boards / meta-96boards

OpenEmbedded BSP Layer for the 96boards.org boards
MIT License
41 stars 59 forks source link

/usr/lib64/libweston-3/gl-renderer.so contained in package libweston-3 requires libEGL.so()(64bit), but no providers found in RDEPENDS_libweston-3? [file-rdeps] #195

Open shibo1802 opened 6 years ago

shibo1802 commented 6 years ago

I'm trying to build rpb-weston-image with https://github.com/96boards/oe-rpb-manifest.git master branch, but encounter many errors related to graphics libraries dependencies, following is the error log

ERROR: weston-3.0.0-r0 do_package_qa: QA Issue: /usr/bin/weston-simple-egl contained in package weston-examples requires libEGL.so()(64bit), but no providers found in RDEPENDS_weston-examples? [file-rdeps] ERROR: weston-3.0.0-r0 do_package_qa: QA Issue: /usr/lib64/libweston-3/gl-renderer.so contained in package libweston-3 requires libEGL.so()(64bit), but no providers found in RDEPENDS_libweston-3? [file-rdeps] ERROR: weston-3.0.0-r0 do_package_qa: QA Issue: /usr/lib64/libweston-3/gl-renderer.so contained in package libweston-3 requires libGLESv2.so()(64bit), but no providers found in RDEPENDS_libweston-3? [file-rdeps] ERROR: weston-3.0.0-r0 do_package_qa: QA Issue: /usr/lib64/libweston-3/wayland-backend.so contained in package libweston-3 requires libwayland-egl.so()(64bit), but no providers found in RDEPENDS_libweston-3? [file-rdeps] ERROR: weston-3.0.0-r0 do_package_qa: QA Issue: /usr/lib64/libweston-3/drm-backend.so contained in package libweston-3 requires libgbm.so()(64bit), but no providers found in RDEPENDS_libweston-3? [file-rdeps] ERROR: weston-3.0.0-r0 do_package_qa: QA run found fatal errors. Please consider fixing them. ERROR: weston-3.0.0-r0 do_package_qa: Function failed: do_package_qa

But the libraries do exist:

./build-rpb-wayland/tmp-rpb_wayland-glibc/work/aarch64-linaro-linux/kmscube/git-r0/recipe-sysroot/usr/lib64/libwayland-egl.so ./build-rpb-wayland/tmp-rpb_wayland-glibc/work/aarch64-linaro-linux/cogl-1.0/1.22.2-r0/recipe-sysroot/usr/lib64/libwayland-egl.so ./build-rpb-wayland/tmp-rpb_wayland-glibc/work/aarch64-linaro-linux/gstreamer1.0-plugins-bad/1.12.3-r0/recipe-sysroot/usr/lib64/libwayland-egl.so ./build-rpb-wayland/tmp-rpb_wayland-glibc/work/aarch64-linaro-linux/libsdl2/2.0.7-r0/recipe-sysroot/usr/lib64/libwayland-egl.so ./build-rpb-wayland/tmp-rpb_wayland-glibc/work/aarch64-linaro-linux/weston/3.0.0-r0/recipe-sysroot/usr/lib64/libwayland-egl.so ./build-rpb-wayland/tmp-rpb_wayland-glibc/work/aarch64-linaro-linux/ffmpeg/3.3.4-r0/recipe-sysroot/usr/lib64/libwayland-egl.so ./build-rpb-wayland/tmp-rpb_wayland-glibc/work/aarch64-linaro-linux/clutter-1.0/1.26.2-r0/recipe-sysroot/usr/lib64/libwayland-egl.so ./build-rpb-wayland/tmp-rpb_wayland-glibc/sysroots-components/hikey/mali450-userland/usr/lib64/libwayland-egl.so

Does anyone encounter the same issue or know how to fix it? Any suggestions would be appreciated.

fboudra commented 6 years ago

hikey is broken in Rocko and Master. @mrchapp is working on it.

shibo1802 commented 6 years ago

Thanks, @fboudra

kraj commented 6 years ago

this issue is due to missing DT_SONAME entry in the precompiled mali shared library, actually someone should report this to mali team so they can add a proper soname during build before publishing.

OE shlib code checks for DT_NEEDED against a set of shlibs for deps however if thse shared libs do not have DT_SONAME then it does not create a rprovides for these sonames

Long story short you can workaround this by inserting a soname e.g. something like below will help your case

https://github.com/akuster/meta-odroid/blob/master/recipes-graphics/mali/mali-450_r6p1.bb#L29

wookey commented 6 years ago

I reported this to the team (along with some other issues I found doing the debian packaging). There was a suggestion that this lack of proper versioning may be deliberate, because the same binary pretends to be several different libraries with different soversions (libEGL.so.1 , libGLESv1_CM.so.1, libGLESv2.so.2, libOpenCL.so.1) so maybe it's not clear what DT_SONAME it should be using? The original reasoning may be lost in the mists of time.

This case is a good example of why it's a real-world problem. I'll feed that back.