Thank you, Quentin.

Hi Rudolf,

On 8/25/22 16:30, Rudolf J Streif wrote:

I am packaging a binary package that has been built with the SDK created with the exact same configuration.

During do_package I am getting an error that a dependency on libGLESv2.so()(64bit) cannot be met. Adding mesa to RDEPENDS does not resolve the issue. I can bypass it in the recipe by adding file-rdeps to INSANE_SKIP. However, then when the rootfs is created libdnf complains that the dependency on libGLES is not met and aborts.

The application works just fine on the target if I copy it manually to the rootfs but that's not the best thing to do. It should be packaged and installed.

Unfortunately I don't understand well enough how these checks work and why they are complaining about it. Maybe somebody can shed some light on it.

Bitbake versions its shared libraries. So a binary built by Bitbake will link against libGLESv2.so.1.3 (or whatever the version of the lib actually is).

This also means that the only shared library that can be used for linking is the versioned one.

Bitbake reads the NEEDED section from objdump to identify the runtime dependencies and automatically add the packages providing those libraries to your image. This is the reason why you do not need to explicit RDEPENDS for packages created by recipes in DEPENDS.

The issue here is that Bitbake creates a package which provides libGLESv2.so.1.3 but your binary requires libGLESv2.so and Bitbake cannot find a package for it.

Yes, that is exactly the issue:

 0x0000000000000001 (NEEDED)             Shared library: [libQt5Quick.so.5]
 0x0000000000000001 (NEEDED)             Shared library: [libQt5Gui.so.5]
 0x0000000000000001 (NEEDED)             Shared library: [libQt5Qml.so.5]
 0x0000000000000001 (NEEDED)             Shared library: [libQt5Network.so.5]
 0x0000000000000001 (NEEDED)             Shared library: [libQt5SerialPort.so.5]
 0x0000000000000001 (NEEDED)             Shared library: [libQt5Core.so.5]
 0x0000000000000001 (NEEDED)             Shared library: [librt.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libatomic.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libGLESv2.so]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

The question is what causes this if the application is built with the toolchain and against the rootfs that YP produces.

Usually the way to do it is to ignore the warning like you did, or build the binary in Yocto directly. I assume the latter is not possible because it is proprietary software compiled by a third-party and you don't have access to the source code.

As to how to fix this issue with dnf, I do not know.

One possibility could be to patchelf your binary in Yocto directly but you'll need to update this patchelf line every time you update libGLESv2 version because it is not possible to get the version from one recipe in another.

Cheers,
Quentin

-- 
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700