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

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

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 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

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 ?

Thanks,
Rudi

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

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.

Thanks,
Rudi

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

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.

Thanks,
Rudi

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

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.

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

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.

Thanks,
Rudi

Hi Everyone,

QA for yocto-3.1.19.rc1 is completed. This is the full report for this release:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

======= Summary ========
No high milestone defects.

No new issue found.

Thanks,
Jay

On Wed, 2022-08-24 at 16:37 +0200, Maik Vermeulen wrote:

Hi Richard,

Thanks, that seems like pretty much what I need!
However, currently the recipes in the dependency chain don't all
contain 'native' counterparts. 
Most actually wouldn't really need to for the executable to be
built. 
Is there a way to neatly work around this too?

DEPENDS = "<full set>"
DEPENDS:class-native = "<more restricted set>"

and variations of this for other kinds of variables are one
possibility. It all really depends.

Cheers,

Richard

On Wed, 2022-08-24 at 14:18 +0200, Maik Vermeulen wrote:

Hi,

We have a recipe with a CMake project which works fine on target, but
ideally we would like to test functionality on our host systems
first.
How can we also have it generate executables for the host system?

Do we need to make changes to the recipe, CMakeLists.txt, or both?
I read something about autotools, but it's completely new to me.

Any hints on what the easiest approach would be would be greatly
appreciated!

BBCLASSEXTEND = "native"

would create a variant of the recipe X as X-native which would run on
the build host. That may or may not be what you're looking for :)

Cheers,

Richard