On 8/25/22 5:44 PM, Khem Raj wrote:

On Thu, Aug 25, 2022 at 4:56 PM Rudolf J Streif
<rudolf.streif@...> wrote:

On 8/25/22 4:49 PM, Khem Raj wrote:

On Thu, Aug 25, 2022 at 4:44 PM Rudolf J Streif
<rudolf.streif@...> wrote:

Thanks, Khem.

On 8/25/22 4:27 PM, Khem Raj wrote:

On Thu, Aug 25, 2022 at 7:30 AM Rudolf J Streif
<rudolf.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.

some libraries do not set SONAME in them, which can trip the shlibs
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.

libGLESv2 in question on the target was built with YP:

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 ?

Yes, but that does not satisfy the dependency:

ERROR: virtuoso-0.1-r0 do_package_qa: QA Issue: /opt/virtuoso/virtuoso
contained in package virtuoso requires libGLESv2.so()(64bit), but no
providers found in RDEPENDS:virtuoso? [file-rdeps]

I see a potential problem here, the soname is libGLESv2.so.2 but the
dependency its
complaining about is libGLESv2.so()(64bit), ( you see the missing
version number ?)

Can you run

readelf -d <binary name> | grep NEEDED

and see what libs are encoded in the ELF

Yes, I have. These are the libs:

 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]

It's asking for libGLESv2.so. It's no problem on the target since it's correctly resolved by ldd:

root@tgt-lcd7:/usr/lib# ldconfig -p |grep libGLES
    libGLESv2.so.2 (libc6,x86-64) => /lib64/libGLESv2.so.2
    libGLESv2.so.2 (libc6) => /lib/libGLESv2.so.2
    libGLESv2.so (libc6,x86-64) => /lib64/libGLESv2.so
    libGLESv1_CM.so.1 (libc6,x86-64) => /lib64/libGLESv1_CM.so.1
    libGLESv1_CM.so.1 (libc6) => /lib/libGLESv1_CM.so.1
    libGLESv1_CM.so (libc6,x86-64) => /lib64/libGLESv1_CM.so

However, I cannot wrap my head around why this would happen with a binary that has been compiled and linked with the YP SDK that exactly matches the rootfs of the target:

Target:

root@tgt-lcd7:/usr/lib# ls -l libGLES*
lrwxrwxrwx 1 root root    14 Mar  9  2018 libGLESv2.so -> libGLESv2.so.2
lrwxrwxrwx 1 root root    18 Mar  9  2018 libGLESv2.so.2 -> libGLESv2.so.2.0.0
-rwxr-xr-x 1 root root 46792 Mar  9  2018 libGLESv2.so.2.0.0

SDK:

[rstreif@threaddy lib]$ ls -l libGLES*
lrwxrwxrwx. 1 rstreif rstreif    14 Aug 25 11:35 libGLESv2.so -> libGLESv2.so.2
lrwxrwxrwx. 1 rstreif rstreif    18 Aug 25 11:36 libGLESv2.so.2 -> libGLESv2.so.2.0.0
-rwxr-xr-x. 1 rstreif rstreif 46792 Aug 25 11:36 libGLESv2.so.2.0.0

Unfortunately I don't have the sources of the application otherwise I would have YP build it. But the customer claims they are building it with the SDK. I am trying to get to the bottom of their end too.

I can SKIP_INSANE file-rdeps but then I am getting the same issue when
creating the rootfs with dnf.

But in all fairness, I don't have control over the entire process. The
customer builds the executable with the SDK I gave them. They give me
the executable to put in the rootfs.

Thanks,
Rudi

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

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

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