This is the problem link. So either the sdk has provided them faulty install or they have replaced some stuff knowiingly or unknowingly or they have environment issues where their make system is

I'm having the exact same issue when just modifying a custom linux recipie which is essntially the same as the one provided but referencing 5.15 after transposing recipies from dunfell to kirkstone.

Yes, I have. These are the libs:  0x0000000000000001 (NEEDED) Shared library: [libQt5Quick.so.5]  0x0000000000000001 (NEEDED)             Shared library:

[ In the future, please make sure to reply to list and not just to me. ] [ Top posting since Outlook doesn’t support inline responses to HTML mails. ] No, you are supposed to copy the suggest

From: Ross Burton <ross.burton@...> Although bitbake.conf sets the default SDKMACHINE to the build architecture, config.json resets that to i686. As oe-selftest assumes that the SDKs it builds

Hi All, I am trying to run qml-launcher (https://github.com/alamminsalo/qml-launcher) with yocto 4.0 kirkstone. I've implemented a service file to start this qml-launcher (service file attached) but

Hello Yocto Experts, I have a minor question regarding how to manage multiple projects within Yocto with MACHINE_FEATURES, DISTRO_FEATURES and IMAGE_FEATURES. If I have one HW platform but two images,

Hi We are pleased to announce the Yocto Project 3.1.19 (dunfell-23.0.19) Release is now available for download.

<rudolf.streif@...> wrote: 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

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

<rudolf.streif@...> wrote: interesting, are you adding RDEPENDS on libgles2-mesa ?

Thanks, Khem. libGLESv2 in question on the target was built with YP:  0x000000000000000e (SONAME)             Library soname: [libGLESv2.so.2] The SDK that builds the application was

<rudolf.streif@...> wrote: 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>

Thank you, Quentin. On 8/25/22 7:45 AM, Quentin Schulz wrote: Yes, that is exactly the issue: 0x0000000000000001 (NEEDED) Shared library:

Wiki: https://wiki.yoctoproject.org/wiki/Bug_Triage Attendees: Steve Sakoman, Joshua Watt, Randy Macleod, Richard Purdie, Alexandre Belloni, Stephen Jolley, Ross Burton, Saul

Hi Rudolf, 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

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

Hi Everyone, QA for yocto-3.1.19.rc1 is completed. This is the full report for this release:

Hello yocto users, I’m trying to add modphp to my project, since there isn’t a dedicated modphp recipe anymore I added an php bbappend with: PACKAGECONFIG:append = " apache2" According to

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