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