On Thu, Aug 25, 2022 at 4:44 PM Rudolf J Streif
On 8/25/22 4:27 PM, Khem Raj wrote:
On Thu, Aug 25, 2022 at 7:30 AM Rudolf J StreiflibGLESv2 in question on the target was built with YP:
I am packaging a binary package that has been built with the SDK createdsome libraries do not set SONAME in them, which can trip the shlibs
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
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.
code. Can you
check if libgles in question has SONAME encoded in its ELF header
readelf -d <lib> | grep SONAME
might be what you can use to deduce it.
0x000000000000000e (SONAME) Library soname: [libGLESv2.so.2]
The SDK that builds the application was built with the same YP setup.
That's why I am scratching my head.
interesting, are you adding RDEPENDS on libgles2-mesa ?
Rudolf J Streif