Date   

Qt based application fails to start with error "Could not initialize egl display" with Yocto Kirkstone

Rasool, Ansar <Ansar_Rasool@...>
 

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 systemd fails to start the service with logs saying "Could not initialize egl display". However, if i run qml-launcher binary without service on wayland terminal, it works just fine.

The same service file and same qml-launcher application worked fine as a service with yocto dunfell, but there seems to be some issue with weston in kirkstone release.
Hoping for a valuable input here.


Regards,
Ansar Rasool


Multiple Images on the same HW platform with one image recipe

an010@...
 

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, where the latter one contains a bit more applications, am I supposed to have one MACHINE, one DISTRO and 2 IMAGES? Or maybe one IMAGE but somehow to define IMAGE_FEATURES / EXTRA_IMAGE_FEATURES differently in those two cases? Due to simplicity, I would rather have one image recipe. 

Whats the best way to achieve this? Thanks. 


Yocto Project 3.1.19 (dunfell-23.0.19) is Released

Lee Chee Yang
 

Hi

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

 

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.19/poky-dunfell-23.0.19.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.19/poky-dunfell-23.0.19.tar.bz2

 

A gpg signed version of these release notes is available at:

 

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.19/RELEASENOTES

 

Full Test Report:

 

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.19/testreport.txt

 

Thank you for everyone's contributions to this release.

 

Chee Yang Lee chee.yang.lee@...

Yocto Project Build and Release


- --------------------------

yocto-3.1.19 Release Notes

- --------------------------

 

 

- --------------------------

Repositories/Downloads

- --------------------------

 

Repository Name: poky

Repository Location: https://git.yoctoproject.org/git/poky

Branch: dunfell

Tag: yocto-3.1.19

Git Revision: 4aad5914efe9789755789856882aac53de6c4ed3

Release Artefact: poky-dunfell-23.0.19

sha: d60e2b374e8fbb2560493a163b87f0e215795daa92d812252995af9365bd53f0

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.19/poky-dunfell-23.0.19.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.19/poky-dunfell-23.0.19.tar.bz2

 

Repository Name: openembedded-core

Repository Location: https://git.openembedded.org/openembedded-core

Branch: dunfell

Tag: yocto-3.1.19

Git Revision: a3cba15142e98177119ef36c09f553d09acf35ef

Release Artefact: oecore-dunfell-23.0.19

sha: 08e66325f4e59df61790fa577626caf9fa0895db12c55407b95728916ea7597b

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.19/oecore-dunfell-23.0.19.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.19/oecore-dunfell-23.0.19.tar.bz2

 

Repository Name: meta-mingw

Repository Location: https://git.yoctoproject.org/git/meta-mingw

Branch: dunfell

Tag: yocto-3.1.19

Git Revision: 524de686205b5d6736661d4532f5f98fee8589b7

Release Artefact: meta-mingw-dunfell-23.0.19

sha: ce55e5a82c51537b3900127f83c8239c7fc914a2f04ac3c8e6994cde881aeafc

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.19/meta-mingw-dunfell-23.0.19.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.19/meta-mingw-dunfell-23.0.19.tar.bz2

 

Repository Name: meta-gplv2

Repository Location: https://git.yoctoproject.org/git/meta-gplv2

Branch: dunfell

Tag: yocto-3.1.19

Git Revision: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac

Release Artefact: meta-gplv2-dunfell-23.0.19

sha: 04dc6ed5adf36b13da082cba8abf5760069c07b91590389cfce33f2b852d6d3d

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.19/meta-gplv2-dunfell-23.0.19.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.19/meta-gplv2-dunfell-23.0.19.tar.bz2

 

Repository Name: bitbake

Repository Location: https://git.openembedded.org/bitbake

Branch: dunfell

Tag: yocto-3.1.19

Git Revision: 17be38290d1e971cd89785e6bf44caef0a6416f8

Release Artefact: bitbake-dunfell-23.0.19

sha: 5b6550fa76d59cb63ee15747db2c7441286a2f8d2d5296126ce4d86bbb189bea

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.19/bitbake-dunfell-23.0.19.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.19/bitbake-dunfell-23.0.19.tar.bz2

 

Repository Name: yocto-docs

Repository Location: https://git.yoctoproject.org/git/yocto-docs

Branch: dunfell

Tag: yocto-3.1.19

Git Revision: 95e030ec74f69eccabcc97737c8a93fd7629f9d9

 

 

- ---------------

Known Issues

- ---------------

N/A

 

 

- ---------------

Security Fixes

- ---------------

gdk-pixbuf: Fix CVE-2021-46829

gnupg: Fix CVE-2022-34903

gnutls: Fix CVE-2022-2509

grub2: Fix CVE-2021-3695 CVE-2021-3696 CVE-2021-3697 CVE-2022-28733 CVE-2022-28734 CVE-2022-28736

libTiff: Fix CVE-2022-2056 CVE-2022-2057 CVE-2022-2058

libjpeg-turbo: Fix CVE-2021-46822

libtirpc: Fix CVE-2021-46828

qemu: Fix CVE-2020-27821 CVE-2022-35414

zlib: Fix CVE-2022-37434

 

 

- ---------------

Fixes

- ---------------

bin_package: install into base_prefix

bitbake: fetch2/wget: Update user-agent

build-appliance-image: Update to dunfell head revision

cve_check: skip remote patches that haven't been fetched when searching for CVE tags

documentation: update for 3.1.19 release

gstreamer1.0: use the correct meson option for the capabilities

initscripts: run umountnfs as a KILL script

insane: Fix buildpaths test to work with special devices

kernel-arch: Fix buildpaths leaking into external module compiles

kernel-fitimage.bbclass: add padding algorithm property in config nodes

libmodule-build-perl: Use env utility to find perl interpreter

libxml2: Port gentest.py to Python-3

linux-firmware: update 20220610 -> 20220708

linux-firwmare: restore WHENCE_CHKSUM variable

linux-yocto/5.4: update to v5.4.209

openssh: Add openssh-sftp-server to openssh RDEPENDS

poky.conf: bump version for 3.1.19 release

rootfs-postcommands.bbclass: move host-user-contaminated.txt to ${S}

selftest: skip virgl test on fedora 36

vim: Upgrade to 9.0.0115


Re: Dependency for binary package

Khem Raj
 

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


Re: Dependency for binary package

Rudolf J Streif
 

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


Re: Dependency for binary package

Khem Raj
 

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


Re: Dependency for binary package

Rudolf J Streif
 

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


Re: Dependency for binary package

Khem Raj
 

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




Re: Dependency for binary package

Rudolf J Streif
 

Thank you, Quentin.

On 8/25/22 7:45 AM, Quentin Schulz wrote:
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


Minutes: Yocto Project Weekly Triage Meeting 8/25/2022

sakib.sajal@...
 

Wiki: https://wiki.yoctoproject.org/wiki/Bug_Triage

Attendees: Steve Sakoman, Joshua Watt, Randy Macleod, Richard Purdie, Alexandre Belloni, Stephen Jolley, Ross Burton, Saul Wold, Tim Orling

ARs:

N/A

Notes:
- Tim will raise issue with Armin regarding BOF

Medium+ 4.1 Unassigned Enhancements/Bugs: 72 (Last week 78)

Medium+ 4.99 Unassigned Enhancements/Bugs: 43 (Last week 43)

AB Bugs: 58 (Last week 56)


Re: Dependency for binary package

Quentin Schulz
 

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


Dependency for binary package

Rudolf J Streif
 

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


Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.1.19.rc1)

Teoh, Jay Shen
 

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

-----Original Message-----
From: qa-build-notification@... <qa-build-
notification@...> On Behalf Of Pokybuild User
Sent: Tuesday, 23 August, 2022 5:59 AM
To: yocto@...
Cc: qa-build-notification@...
Subject: [qa-build-notification] QA notification for completed autobuilder
build (yocto-3.1.19.rc1)


A build flagged for QA (yocto-3.1.19.rc1) was completed on the autobuilder
and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.1.19.rc1


Build hash information:

bitbake: 17be38290d1e971cd89785e6bf44caef0a6416f8
meta-agl: 8ce71214c1935c2160d139140972f328afacabee
meta-arm: 69547052727a461f33967e64630aa03b34a7eadd
meta-aws: bc38cc397e98c6d6d8d4b701de5944f72d169108
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: 8ed6f20cfb116e88e573ee6a08637aa5ac12e1c5
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
meta-openembedded: f22bf6efaae61a8fd9272be64e7d75223c58922e
meta-virtualization: a63a54df3170fed387f810f23cdc2f483ad587df
oecore: a3cba15142e98177119ef36c09f553d09acf35ef
poky: 4aad5914efe9789755789856882aac53de6c4ed3



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...







Failing to add modphp httpd.conf missing php-native

Duda, Alexander
 

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 meta-openembedded/meta-webserver/README

 

But bitbake is telling me that during compile of php-native apxs is missing the httpd.conf

 

DEBUG: Appending .bbappend file /home/…/recipes-devtools/php/php_%.bbappend to /home/…/meta-openembedded/meta-oe/recipes-devtools/php/php_7.4.21.bb

DEBUG: Appending .bbappend file /home/…/build/workspace/appends/php_7.4.21.bbappend to /home/…/meta-openembedded/meta-oe/recipes-devtools/php/php_7.4.21.bb

DEBUG: php-native-7.4.21-r0 do_install: Executing python function autotools_aclocals

DEBUG: php-native-7.4.21-r0 do_install: SITE files ['endian-little', 'common-linux', 'common-glibc', 'bit-64', 'x86_64-linux', 'common']

DEBUG: php-native-7.4.21-r0 do_install: Python function autotools_aclocals finished

DEBUG: php-native-7.4.21-r0 do_install: Executing shell function do_install

ERROR: php-native-7.4.21-r0 do_install: oe_runmake failed

ERROR: php-native-7.4.21-r0 do_install: ExecutionError('/home/…/build/tmp/work/x86_64-linux/php-native/7.4.21-r0/temp/run.do_install.104056', 1, None, None)

ERROR: Logfile of failure stored in: /home/.../build/tmp/work/x86_64-linux/php-native/7.4.21-r0/temp/log.do_install.104056

| apxs:Error: Config file /home/…./build/tmp/work/x86_64-linux/php-native/7.4.21-r0/image/home/…./build/tmp/work/x86_64-linux/php-native/7.4.21-r0/recipe-sysroot-native/etc/apache2/httpd.conf not found.

 

Is there a way to deploy a dummy httpd.conf to this location or any other fix to get this working?

 

Best regards,

 

Alex

 

 


Re: Building for both target and host

Richard Purdie
 

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


Re: Building for both target and host

Alexander Kanavin
 

One option is to actually build an image for a qemux86_64 machine with the items you need (or qemuarm64 if that's your build host), then use 'runqemu kvm' to get native execution speed in a fully virtualized environment. 'native' recipes are generally meant as a springboard to get the binaries that are needed to build target recipes, and not a way to do 'native testing'.

Alex


On Wed, 24 Aug 2022 at 16:38, Maik Vermeulen <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?

Kind regards,

Maik Vermeulen

Embedded Software Engineer — Lightyear


On Wed, Aug 24, 2022 at 3:01 PM Richard Purdie <richard.purdie@...> wrote:
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








Automotive Campus 70 —5708 JZ Helmond, the Netherlands

This email may contain information which is privileged and/or confidential. If you received this e-mail in error, please notify us immediately by e-mail and delete the email without copying or disclosing its contents to any other person. Lightyear is a trade name of Atlas Technologies B.V. and is registered at the Dutch Chamber of Commerce under number 67264298. 




Re: Building for both target and host

Maik Vermeulen
 

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?

Kind regards,

Maik Vermeulen

Embedded Software Engineer — Lightyear


On Wed, Aug 24, 2022 at 3:01 PM Richard Purdie <richard.purdie@...> wrote:
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








Automotive Campus 70 —5708 JZ Helmond, the Netherlands

This email may contain information which is privileged and/or confidential. If you received this e-mail in error, please notify us immediately by e-mail and delete the email without copying or disclosing its contents to any other person. Lightyear is a trade name of Atlas Technologies B.V. and is registered at the Dutch Chamber of Commerce under number 67264298. 


Re: Bitbake + Patches

Peter Kjellerstedt
 

-----Original Message-----
From: forums <forums@...>
Sent: den 23 augusti 2022 22:34
To: Peter Kjellerstedt <peter.kjellerstedt@...>
Subject: Re: [yocto] Bitbake + Patches

Thanks Peter. I will look into this. But isn’t this bbappend considered a
patch as well or will replace Apache 2.4.41 with the latest version of
apache?
Well, it depends on how strict your terminology is. To me, a patch is a
file, typically generated by `diff` or `git format-patch`. But of course,
adding the bbappend suggested below will modify the recipe so that it
builds the latest version of Apache.

I am relatively new to yocto so there’s a lot I need to learn.

Jim

On Aug 23, 2022, at 7:41 AM, Peter Kjellerstedt <peter.kjellerstedt@...> wrote:

-----Original Message-----
From: yocto@... <yocto@...> On Behalf Of Khem Raj
Sent: den 23 augusti 2022 00:29
To: bitflipper <forums@...>
Cc: yocto@...
Subject: Re: [yocto] Bitbake + Patches

On Mon, Aug 22, 2022 at 1:54 PM bitflipper <forums@...> wrote:

I was told this was the right group to ask my question. If this is
not right, please let me know.

I am currently using Zeus, and with Zeus, we get Apache v2.4.41.
But I would like to get a later version of apache because there
have been a few fixes related to cyber security. So I believe that,
given we’re using Zeus, we can’t upgrade to the latest version of
Apache given the current recipe that Zeus uses. Therefore I believe
that the only way accomplish getting tho the latest version of
apache with Zeus would to be ‘patch’ the v2.4.41 version that comes
with Zeus.

Looking at the Bitbake manual, in section 4.1, it states the
following:

"BitBake takes several steps when fetching source code or files.
The fetcher codebase deals with two distinct processes in order:
obtaining the files from somewhere (cached or otherwise) and then
unpacking those files into a specific location and perhaps in a
specific way. Getting and unpacking the files is often optionally
followed by patching. Patching, however, is not covered by this
module."

The manual does not cover patching.

Where can I get information on this process of patching something like
apache or any other application that was add via IMAGE_INSTALL_append
method.

Any help pointing me to where this process might be documented is much
appreciated.
look into mega manual something like this would help
https://docs.yoctoproject.org/dev-manual/common-tasks.html?highlight=writing+recipe#patching-code

Thanks, Jim
You don't really need to go patching apache just to update it. What you
need is to add a bbappend file in one of your own layers. Call it
recipes-httpd/apache2/apache2_2.4.41.bbappend and make it contain:

FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:"

LIC_FILES_CHKSUM = "file://LICENSE;md5=bddeddfac80b2c9a882241d008bb41c3"

PV = "2.4.54"

SRC_URI += "file://0008-Fix-perl-install-directory-to-usr-bin.patch \
file://0009-support-apxs.in-force-destdir-to-be-empty-string.patch \
file://0001-make_exports.awk-not-expose-the-path.patch"
SRC_URI_remove = "file://apache-configure_perlbin.patch"

SRC_URI[md5sum] = "<I don't have this at hand, but bitbake will tell you what it should be>"
SRC_URI[sha256sum] = "eb397feeefccaf254f8d45de3768d9d68e8e73851c49afd5b7176d1ecf80c340"

You then also need to copy the three new patches and any other
patches that differs between zeus and master and put them in your
layer together with the bbappend file (in a subdirectory called
"recipes-httpd/apache2/apache2").

The suggested contents of the bbappend above is based on the
differences between the apache2 recipe in zeus and master.

//Peter
//Peter


Re: Building for both target and host

Richard Purdie
 

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


Building for both target and host

Maik Vermeulen
 

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!

Kind regards,

Maik Vermeulen

Embedded Software Engineer — Lightyear






Automotive Campus 70 —5708 JZ Helmond, the Netherlands

This email may contain information which is privileged and/or confidential. If you received this e-mail in error, please notify us immediately by e-mail and delete the email without copying or disclosing its contents to any other person. Lightyear is a trade name of Atlas Technologies B.V. and is registered at the Dutch Chamber of Commerce under number 67264298. 

1181 - 1200 of 59039