[PATCH 0/3] ovmf: add some rework to the recipe

[PATCH 0/3] ovmf: add some rework to the recipe

[João Marcos Costa]

Hello,

This patch series contains, first of all, a slight issue with PACKAGECONFIG
previously evoked by Q. Schulz (cc'ed) in the mailing list.

The main point of the series is the support for Clang, which I tested with the
latest version llvm/clang available as of now in oe-core. I also tested the
result with the help of runqemu.

Moreover, some of the settings are obsolete and can be removed.

Best regards,

João Marcos Costa (3):
  ovmf: simplify PACKAGECONFIG's default value
  ovmf: drop gcc-12 specific BUILD_CFLAGS setting
  ovmf: add support for Clang toolchain

 meta/recipes-core/ovmf/ovmf_git.bb | 51 ++++++------------------------
 1 file changed, 9 insertions(+), 42 deletions(-)

-- 
2.47.0

[PATCH 1/3] ovmf: simplify PACKAGECONFIG's default value

[João Marcos Costa]

The two append operations call bb.utils.contains, while a single
contains_any() does the trick in a cleaner way.

Regarding the default value, if tpm is not enabled, PACKAGECONFIG ends
up with a couple empty spaces, and this can be avoided by redefining the
default value to the result of contains_any().

Signed-off-by: João Marcos Costa <joaomarcos.costa@bootlin.com>
---
 meta/recipes-core/ovmf/ovmf_git.bb | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/meta/recipes-core/ovmf/ovmf_git.bb b/meta/recipes-core/ovmf/ovmf_git.bb
index 958f42fc10..779e9f8196 100644
--- a/meta/recipes-core/ovmf/ovmf_git.bb
+++ b/meta/recipes-core/ovmf/ovmf_git.bb
@@ -9,9 +9,7 @@ LIC_FILES_CHKSUM = "file://OvmfPkg/License.txt;md5=06357ddc23f46577c2aeaeaf7b776
 # Enabling Secure Boot adds a dependency on OpenSSL and implies
 # compiling OVMF twice, so it is disabled by default. Distros
 # may change that default.
-PACKAGECONFIG ??= ""
-PACKAGECONFIG += "${@bb.utils.filter('MACHINE_FEATURES', 'tpm', d)}"
-PACKAGECONFIG += "${@bb.utils.contains('MACHINE_FEATURES', 'tpm2', 'tpm', '', d)}"
+PACKAGECONFIG ?= "${@bb.utils.contains_any('MACHINE_FEATURES', 'tpm tpm2', 'tpm', '', d)}"
 PACKAGECONFIG[debug] = ",,,"
 PACKAGECONFIG[secureboot] = ",,,"
 PACKAGECONFIG[tpm] = "-D TPM_ENABLE=TRUE,-D TPM_ENABLE=FALSE,,"
-- 
2.47.0

[PATCH 2/3] ovmf: drop gcc-12 specific BUILD_CFLAGS setting

[João Marcos Costa]

This was handled upstream a while ago:

https://github.com/tianocore/edk2/blob/master/BaseTools/Source/C/DevicePath/GNUmakefile#L27

Signed-off-by: João Marcos Costa <joaomarcos.costa@bootlin.com>
---
 meta/recipes-core/ovmf/ovmf_git.bb | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/meta/recipes-core/ovmf/ovmf_git.bb b/meta/recipes-core/ovmf/ovmf_git.bb
index 779e9f8196..8e2d172f66 100644
--- a/meta/recipes-core/ovmf/ovmf_git.bb
+++ b/meta/recipes-core/ovmf/ovmf_git.bb
@@ -14,10 +14,6 @@ PACKAGECONFIG[debug] = ",,,"
 PACKAGECONFIG[secureboot] = ",,,"
 PACKAGECONFIG[tpm] = "-D TPM_ENABLE=TRUE,-D TPM_ENABLE=FALSE,,"
 
-# GCC12 trips on it
-#see https://src.fedoraproject.org/rpms/edk2/blob/rawhide/f/0032-Basetools-turn-off-gcc12-warning.patch
-BUILD_CFLAGS += "-Wno-error=stringop-overflow"
-
 SRC_URI = "gitsm://github.com/tianocore/edk2.git;branch=master;protocol=https;tag=${PV} \
            file://0001-ovmf-update-path-to-native-BaseTools.patch \
            file://0002-BaseTools-makefile-adjust-to-build-in-under-bitbake.patch \
-- 
2.47.0

[PATCH 3/3] ovmf: add support for Clang toolchain

[João Marcos Costa]

ovmf can be built with clang by using "CLANGDWARF" toolchain, so add
TARGET_TOOLS variable to represent the switch between "GCC" and
"CLANGDWARF".

Since the targets represented by FIXED_GCCVER were deprecated upstream,
remove them (and FIXED_GCCVER itself) from the recipe and use "GCC"
instead.

Signed-off-by: João Marcos Costa <joaomarcos.costa@bootlin.com>
---
 meta/recipes-core/ovmf/ovmf_git.bb | 43 ++++++------------------------
 1 file changed, 8 insertions(+), 35 deletions(-)

diff --git a/meta/recipes-core/ovmf/ovmf_git.bb b/meta/recipes-core/ovmf/ovmf_git.bb
index 8e2d172f66..93380b2ba9 100644
--- a/meta/recipes-core/ovmf/ovmf_git.bb
+++ b/meta/recipes-core/ovmf/ovmf_git.bb
@@ -55,6 +55,7 @@ inherit deploy
 PARALLEL_MAKE = ""
 
 DEPENDS = "nasm-native acpica-native ovmf-native util-linux-native"
+DEPENDS:append:toolchain-clang = " lld-native"
 
 EDK_TOOLS_DIR = "edk2_basetools"
 
@@ -145,39 +146,13 @@ fix_toolchain:append:class-native() {
 export NASM_PREFIX_MAP = "--debug-prefix-map=${WORKDIR}=${TARGET_DBGSRC_DIR}"
 export GCC_PREFIX_MAP = "${DEBUG_PREFIX_MAP} -Wno-stringop-overflow -Wno-maybe-uninitialized"
 
-GCC_VER = "$(${CC} -v 2>&1 | tail -n1 | awk '{print $3}')"
-
-fixup_target_tools() {
-    case ${1} in
-      4.4.*)
-        FIXED_GCCVER=GCC44
-        ;;
-      4.5.*)
-        FIXED_GCCVER=GCC45
-        ;;
-      4.6.*)
-        FIXED_GCCVER=GCC46
-        ;;
-      4.7.*)
-        FIXED_GCCVER=GCC47
-        ;;
-      4.8.*)
-        FIXED_GCCVER=GCC48
-        ;;
-      4.9.*)
-        FIXED_GCCVER=GCC49
-        ;;
-      *)
-        FIXED_GCCVER=GCC5
-        ;;
-    esac
-    echo ${FIXED_GCCVER}
-}
-
 do_compile:class-native() {
     oe_runmake -C ${S}/BaseTools
 }
 
+TARGET_TOOLS ?= "GCC"
+TARGET_TOOLS:toolchain-clang = "CLANGDWARF"
+
 do_compile:class-target() {
     export LFLAGS="${LDFLAGS}"
     PARALLEL_JOBS="${@oe.utils.parallel_make_argument(d, '-n %d')}"
@@ -198,13 +173,12 @@ do_compile:class-target() {
     rm -rf ${WORKDIR}/ovmf
     mkdir ${WORKDIR}/ovmf
     OVMF_DIR_SUFFIX="X64"
-    FIXED_GCCVER=$(fixup_target_tools ${GCC_VER})
-    bbnote FIXED_GCCVER is ${FIXED_GCCVER}
-    build_dir="${S}/Build/Ovmf$OVMF_DIR_SUFFIX/${OVMF_BUILD_TYPE}_${FIXED_GCCVER}"
+    bbnote TARGET_TOOLS is ${TARGET_TOOLS}
+    build_dir="${S}/Build/Ovmf$OVMF_DIR_SUFFIX/${OVMF_BUILD_TYPE}_${TARGET_TOOLS}"
 
     bbnote "Building without Secure Boot."
     rm -rf ${S}/Build/Ovmf$OVMF_DIR_SUFFIX
-    ${S}/OvmfPkg/build.sh $PARALLEL_JOBS -a $OVMF_ARCH -b ${OVMF_BUILD_TYPE} -t ${FIXED_GCCVER} ${PACKAGECONFIG_CONFARGS}
+    ${S}/OvmfPkg/build.sh $PARALLEL_JOBS -a $OVMF_ARCH -b ${OVMF_BUILD_TYPE} -t ${TARGET_TOOLS} ${PACKAGECONFIG_CONFARGS}
     ln ${build_dir}/FV/OVMF.fd ${WORKDIR}/ovmf/ovmf.fd
     ln ${build_dir}/FV/OVMF_CODE.fd ${WORKDIR}/ovmf/ovmf.code.fd
     ln ${build_dir}/FV/OVMF_VARS.fd ${WORKDIR}/ovmf/ovmf.vars.fd
@@ -214,7 +188,7 @@ do_compile:class-target() {
         # Repeat build with the Secure Boot flags.
         bbnote "Building with Secure Boot."
         rm -rf ${S}/Build/Ovmf$OVMF_DIR_SUFFIX
-        ${S}/OvmfPkg/build.sh $PARALLEL_JOBS -a $OVMF_ARCH -b ${OVMF_BUILD_TYPE} -t ${FIXED_GCCVER} ${PACKAGECONFIG_CONFARGS} ${OVMF_SECURE_BOOT_FLAGS}
+        ${S}/OvmfPkg/build.sh $PARALLEL_JOBS -a $OVMF_ARCH -b ${OVMF_BUILD_TYPE} -t ${TARGET_TOOLS} ${PACKAGECONFIG_CONFARGS} ${OVMF_SECURE_BOOT_FLAGS}
         ln ${build_dir}/FV/OVMF.fd ${WORKDIR}/ovmf/ovmf.secboot.fd
         ln ${build_dir}/FV/OVMF_CODE.fd ${WORKDIR}/ovmf/ovmf.secboot.code.fd
         ln ${build_dir}/${OVMF_ARCH}/EnrollDefaultKeys.efi ${WORKDIR}/ovmf/
@@ -277,4 +251,3 @@ do_deploy:class-target() {
 addtask do_deploy after do_compile before do_build
 
 BBCLASSEXTEND = "native"
-TOOLCHAIN = "gcc"
-- 
2.47.0

Re: [PATCH 1/3] ovmf: simplify PACKAGECONFIG's default value

[Quentin Schulz]

Hi João,

On 5/11/26 11:29 AM, João Marcos Costa wrote:
> The two append operations call bb.utils.contains, while a single
> contains_any() does the trick in a cleaner way.
> 
> Regarding the default value, if tpm is not enabled, PACKAGECONFIG ends
> up with a couple empty spaces, and this can be avoided by redefining the
> default value to the result of contains_any().
> 
> Signed-off-by: João Marcos Costa <joaomarcos.costa@bootlin.com>
> ---
>   meta/recipes-core/ovmf/ovmf_git.bb | 4 +---
>   1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/meta/recipes-core/ovmf/ovmf_git.bb b/meta/recipes-core/ovmf/ovmf_git.bb
> index 958f42fc10..779e9f8196 100644
> --- a/meta/recipes-core/ovmf/ovmf_git.bb
> +++ b/meta/recipes-core/ovmf/ovmf_git.bb
> @@ -9,9 +9,7 @@ LIC_FILES_CHKSUM = "file://OvmfPkg/License.txt;md5=06357ddc23f46577c2aeaeaf7b776
>   # Enabling Secure Boot adds a dependency on OpenSSL and implies
>   # compiling OVMF twice, so it is disabled by default. Distros
>   # may change that default.
> -PACKAGECONFIG ??= ""
> -PACKAGECONFIG += "${@bb.utils.filter('MACHINE_FEATURES', 'tpm', d)}"
> -PACKAGECONFIG += "${@bb.utils.contains('MACHINE_FEATURES', 'tpm2', 'tpm', '', d)}"
> +PACKAGECONFIG ?= "${@bb.utils.contains_any('MACHINE_FEATURES', 'tpm tpm2', 'tpm', '', d)}"

Just a heads up that this is *not* equivalent.

The use of ??= meant that any ?= (and ??=) parsed anywhere before that 
line is meant that it would set the default values, and then we would 
append to those default values tpm.

Now by merging those into a single ?=, a previous ?= will override this 
new ?= operator, meaning tpm won't make  it to the PACKAGECONFIG even if 
the MACHINE_FEATURES is set to tpm/tpm2. Also, an earlier ??= won't do 
anything anymore.

Whether that's an actual issue, I don't know, but you may break users.

Merging the two += into a single one would truly be equivalent.

Cheers,
Quentin

Re: [PATCH 2/3] ovmf: drop gcc-12 specific BUILD_CFLAGS setting

[Quentin Schulz]

Hi João,

On 5/11/26 11:29 AM, João Marcos Costa wrote:
> This was handled upstream a while ago:
> 
> https://github.com/tianocore/edk2/blob/master/BaseTools/Source/C/DevicePath/GNUmakefile#L27
> 

It's not because upstream supports it that the version we're building 
has it, so pointing at a commit and mentioning it's part of the version 
we're building would be nice.

22130dcd98b4 ("Basetools: turn off gcc12 warning") part of 
edk2-stable202205 tag (and also edk2-stable202511 which we currently are at.

Also, unclear whether this single file is the only place this flag being 
set would be enough as the flag was set globally and now it's only in a 
specific file within edk2 source code.

Cheers,
Quentin

Re: [OE-core] [PATCH 2/3] ovmf: drop gcc-12 specific BUILD_CFLAGS setting

[Joao Marcos Costa]

Hello,

On 5/11/26 15:27, Quentin Schulz via lists.openembedded.org wrote:
> Hi João,
> 
> On 5/11/26 11:29 AM, João Marcos Costa wrote:
>> This was handled upstream a while ago:
>>
>> https://github.com/tianocore/edk2/blob/master/BaseTools/Source/C/DevicePath/GNUmakefile#L27
>>
> 
> It's not because upstream supports it that the version we're building 
> has it, so pointing at a commit and mentioning it's part of the version 
> we're building would be nice.
> 
> 22130dcd98b4 ("Basetools: turn off gcc12 warning") part of 
> edk2-stable202205 tag (and also edk2-stable202511 which we currently are 
> at.

That's very much true. I will stick with this approach for the next time.

> Also, unclear whether this single file is the only place this flag being 
> set would be enough as the flag was set globally and now it's only in a 
> specific file within edk2 source code.
> 
> Cheers,
> Quentin

In any case, the warnings/errors would have been noticed during the 
build if this flag was still needed (and missing).

-- 
Best regards,
João Marcos Costa

Re: [OE-core] [PATCH 2/3] ovmf: drop gcc-12 specific BUILD_CFLAGS setting

[Quentin Schulz]

Hi João,

On 5/11/26 3:40 PM, Joao Marcos Costa wrote:
> Hello,
> 
> On 5/11/26 15:27, Quentin Schulz via lists.openembedded.org wrote:
>> Hi João,
>>
>> On 5/11/26 11:29 AM, João Marcos Costa wrote:
>>> This was handled upstream a while ago:
>>>
>>> https://eur02.safelinks.protection.outlook.com/? 
>>> url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fblob%2Fmaster%2FBaseTools%2FSource%2FC%2FDevicePath%2FGNUmakefile%23L27&data=05%7C02%7Cquentin.schulz%40cherry.de%7Cd69acb4606d94a43ff0b08deaf62e1b9%7C5e0e1b5221b54e7b83bb514ec460677e%7C0%7C0%7C639141036395687030%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=D5wD6%2Bvq%2BYJP3wUROtdEswwwc4RJFYmYvt7GLzsvJbo%3D&reserved=0
>>>
>>
>> It's not because upstream supports it that the version we're building 
>> has it, so pointing at a commit and mentioning it's part of the 
>> version we're building would be nice.
>>
>> 22130dcd98b4 ("Basetools: turn off gcc12 warning") part of edk2- 
>> stable202205 tag (and also edk2-stable202511 which we currently are at.
> 
> That's very much true. I will stick with this approach for the next time.
> 
>> Also, unclear whether this single file is the only place this flag 
>> being set would be enough as the flag was set globally and now it's 
>> only in a specific file within edk2 source code.
>>
>> Cheers,
>> Quentin
> 
> In any case, the warnings/errors would have been noticed during the 
> build if this flag was still needed (and missing).
> 

Not necessarily true as I don't think we build GCC for native recipes 
(and ovmf has a native variant), so it depends on the GCC on the host 
(unless you have uninative?). I don't know the autobuilder 
infrastructure, e.g. whether we build patches on multiple workers on 
different distros to have a big GCC version test matrix.

But yes, building with a newer GCC will generally not make warnings from 
previous versions disappear and I'm hoping upstream has had time to fix 
warnings returned by GCC12 in the last 4 years :)

Cheers,
Quentin

Re: [OE-core] [PATCH 2/3] ovmf: drop gcc-12 specific BUILD_CFLAGS setting

[Joao Marcos Costa]

Hello,

On 5/11/26 15:52, Quentin Schulz via lists.openembedded.org wrote:
(...)
> 
> Not necessarily true as I don't think we build GCC for native recipes 
> (and ovmf has a native variant), so it depends on the GCC on the host 
> (unless you have uninative?). I don't know the autobuilder 
> infrastructure, e.g. whether we build patches on multiple workers on 
> different distros to have a big GCC version test matrix.
> 
> But yes, building with a newer GCC will generally not make warnings from 
> previous versions disappear and I'm hoping upstream has had time to fix 
> warnings returned by GCC12 in the last 4 years :)
> 
> Cheers,
> Quentin

Yep, my whole point is based on the the distros in SANITY_TESTED_DISTROS 
being recent enough to ship GCC > 12 :)

I should have made it explicit in my commit message.

-- 
Best regards,
João Marcos Costa

Re: [OE-core] [PATCH 2/3] ovmf: drop gcc-12 specific BUILD_CFLAGS setting

[Richard Purdie]

On Mon, 2026-05-11 at 16:00 +0200, Joao Marcos Costa via lists.openembedded.org wrote:
> Hello,
> 
> On 5/11/26 15:52, Quentin Schulz via lists.openembedded.org wrote:
> (...)
> > 
> > Not necessarily true as I don't think we build GCC for native recipes 
> > (and ovmf has a native variant), so it depends on the GCC on the host 
> > (unless you have uninative?). I don't know the autobuilder 
> > infrastructure, e.g. whether we build patches on multiple workers on 
> > different distros to have a big GCC version test matrix.
> > 
> > But yes, building with a newer GCC will generally not make warnings from 
> > previous versions disappear and I'm hoping upstream has had time to fix 
> > warnings returned by GCC12 in the last 4 years :)
> > 
> > Cheers,
> > Quentin
> 
> Yep, my whole point is based on the the distros in SANITY_TESTED_DISTROS 
> being recent enough to ship GCC > 12 :)
> 
> I should have made it explicit in my commit message.

I hate to say this but:

Alma/Centos/Rocky 8 have gcc 8
Debian 11 has gcc 10

and we don't use buildtools on debian 11.

I'm therefore not sure how you concluded that from SANITY_TESTED_DISTROS.

Cheers,

Richard

Re: [OE-core] [PATCH 2/3] ovmf: drop gcc-12 specific BUILD_CFLAGS setting

[Joao Marcos Costa]

Hello,

On 5/12/26 10:46, Richard Purdie wrote:
> On Mon, 2026-05-11 at 16:00 +0200, Joao Marcos Costa via lists.openembedded.org wrote:
>> Hello,
>>
>> On 5/11/26 15:52, Quentin Schulz via lists.openembedded.org wrote:
>> (...)
>>>
>>> Not necessarily true as I don't think we build GCC for native recipes
>>> (and ovmf has a native variant), so it depends on the GCC on the host
>>> (unless you have uninative?). I don't know the autobuilder
>>> infrastructure, e.g. whether we build patches on multiple workers on
>>> different distros to have a big GCC version test matrix.
>>>
>>> But yes, building with a newer GCC will generally not make warnings from
>>> previous versions disappear and I'm hoping upstream has had time to fix
>>> warnings returned by GCC12 in the last 4 years :)
>>>
>>> Cheers,
>>> Quentin
>>
>> Yep, my whole point is based on the the distros in SANITY_TESTED_DISTROS
>> being recent enough to ship GCC > 12 :)
>>
>> I should have made it explicit in my commit message.
> 
> I hate to say this but:
> 
> Alma/Centos/Rocky 8 have gcc 8
> Debian 11 has gcc 10
> 
> and we don't use buildtools on debian 11.
> 
> I'm therefore not sure how you concluded that from SANITY_TESTED_DISTROS.
> 
> Cheers,
> 
> Richard

Ah, my bad...

 From this list here:
https://docs.yoctoproject.org/ref-manual/system-requirements.html#supported-linux-distributions

Considering the versions of Fedora and Ubuntu, I presumed the other 
distros were at least as recent (in terms of packages versions) as 
Fedora 39 (which ships GCC 13).

I will check the results in SWAT to see if this warnings pops up, but 
the commit message could use a rewording to address this point and also 
some questions raised by Quentin, so a v2 will be sent later in this week.

-- 
Best regards,
João Marcos Costa

Re: [OE-core] [PATCH 2/3] ovmf: drop gcc-12 specific BUILD_CFLAGS setting

[Richard Purdie]

On Tue, 2026-05-12 at 11:02 +0200, Joao Marcos Costa wrote:
> Hello,
> 
> On 5/12/26 10:46, Richard Purdie wrote:
> > On Mon, 2026-05-11 at 16:00 +0200, Joao Marcos Costa via lists.openembedded.org wrote:
> > > Hello,
> > > 
> > > On 5/11/26 15:52, Quentin Schulz via lists.openembedded.org wrote:
> > > (...)
> > > > 
> > > > Not necessarily true as I don't think we build GCC for native recipes
> > > > (and ovmf has a native variant), so it depends on the GCC on the host
> > > > (unless you have uninative?). I don't know the autobuilder
> > > > infrastructure, e.g. whether we build patches on multiple workers on
> > > > different distros to have a big GCC version test matrix.
> > > > 
> > > > But yes, building with a newer GCC will generally not make warnings from
> > > > previous versions disappear and I'm hoping upstream has had time to fix
> > > > warnings returned by GCC12 in the last 4 years :)
> > > > 
> > > > Cheers,
> > > > Quentin
> > > 
> > > Yep, my whole point is based on the the distros in SANITY_TESTED_DISTROS
> > > being recent enough to ship GCC > 12 :)
> > > 
> > > I should have made it explicit in my commit message.
> > 
> > I hate to say this but:
> > 
> > Alma/Centos/Rocky 8 have gcc 8
> > Debian 11 has gcc 10
> > 
> > and we don't use buildtools on debian 11.
> > 
> > I'm therefore not sure how you concluded that from SANITY_TESTED_DISTROS.
> > 
> > Cheers,
> > 
> > Richard
> 
> Ah, my bad...
> 
>  From this list here:
> https://docs.yoctoproject.org/ref-manual/system-requirements.html#supported-linux-distributions
> 
> Considering the versions of Fedora and Ubuntu, I presumed the other 
> distros were at least as recent (in terms of packages versions) as 
> Fedora 39 (which ships GCC 13).
> 
> I will check the results in SWAT to see if this warnings pops up, but
> the commit message could use a rewording to address this point and also 
> some questions raised by Quentin, so a v2 will be sent later in this week.

We currently support distros with gcc 10, I think that is clear. 

It may or may not show up on the autobuilder due to sstate reuse, so
relying on that as a way to check this is not appropriate.

Also note:

https://docs.yoctoproject.org/dev/ref-manual/system-requirements.html#required-git-tar-python-make-and-gcc-versions

Personally I'd love to remove this but we simply can't without changing
our documented host requirements.

Cheers,

Richard

Re: [OE-core] [PATCH 2/3] ovmf: drop gcc-12 specific BUILD_CFLAGS setting

[Joao Marcos Costa]

Hello,

On 5/12/26 11:06, Richard Purdie wrote:
> On Tue, 2026-05-12 at 11:02 +0200, Joao Marcos Costa wrote:
>> Hello,
>>
>> On 5/12/26 10:46, Richard Purdie wrote:
>>> On Mon, 2026-05-11 at 16:00 +0200, Joao Marcos Costa via lists.openembedded.org wrote:
>>>> Hello,
>>>>
>>>> On 5/11/26 15:52, Quentin Schulz via lists.openembedded.org wrote:
>>>> (...)
>>>>>
>>>>> Not necessarily true as I don't think we build GCC for native recipes
>>>>> (and ovmf has a native variant), so it depends on the GCC on the host
>>>>> (unless you have uninative?). I don't know the autobuilder
>>>>> infrastructure, e.g. whether we build patches on multiple workers on
>>>>> different distros to have a big GCC version test matrix.
>>>>>
>>>>> But yes, building with a newer GCC will generally not make warnings from
>>>>> previous versions disappear and I'm hoping upstream has had time to fix
>>>>> warnings returned by GCC12 in the last 4 years :)
>>>>>
>>>>> Cheers,
>>>>> Quentin
>>>>
>>>> Yep, my whole point is based on the the distros in SANITY_TESTED_DISTROS
>>>> being recent enough to ship GCC > 12 :)
>>>>
>>>> I should have made it explicit in my commit message.
>>>
>>> I hate to say this but:
>>>
>>> Alma/Centos/Rocky 8 have gcc 8
>>> Debian 11 has gcc 10
>>>
>>> and we don't use buildtools on debian 11.
>>>
>>> I'm therefore not sure how you concluded that from SANITY_TESTED_DISTROS.
>>>
>>> Cheers,
>>>
>>> Richard
>>
>> Ah, my bad...
>>
>>   From this list here:
>> https://docs.yoctoproject.org/ref-manual/system-requirements.html#supported-linux-distributions
>>
>> Considering the versions of Fedora and Ubuntu, I presumed the other
>> distros were at least as recent (in terms of packages versions) as
>> Fedora 39 (which ships GCC 13).
>>
>> I will check the results in SWAT to see if this warnings pops up, but
>> the commit message could use a rewording to address this point and also
>> some questions raised by Quentin, so a v2 will be sent later in this week.
> 
> We currently support distros with gcc 10, I think that is clear.

It is clear, yes, but my point here is the -Wno-error=stringop-overflow 
already being available upstream in the version of edk2 we currently 
use, and - as per what I understood in their git history - the flag was 
added for the very same reason we have it in the recipe.

> 
> It may or may not show up on the autobuilder due to sstate reuse, so
> relying on that as a way to check this is not appropriate.
> 
> Also note:
> 
> https://docs.yoctoproject.org/dev/ref-manual/system-requirements.html#required-git-tar-python-make-and-gcc-versions
> 
> Personally I'd love to remove this but we simply can't without changing
> our documented host requirements.
> 
> Cheers,
> 
> Richard
> 
> 
> 

-- 
Best regards,
João Marcos Costa

Re: [OE-core] [PATCH 2/3] ovmf: drop gcc-12 specific BUILD_CFLAGS setting

[Richard Purdie]

On Tue, 2026-05-12 at 11:17 +0200, Joao Marcos Costa wrote:
> Hello,
> 
> On 5/12/26 11:06, Richard Purdie wrote:
> > On Tue, 2026-05-12 at 11:02 +0200, Joao Marcos Costa wrote:
> > > Hello,
> > > 
> > > On 5/12/26 10:46, Richard Purdie wrote:
> > > > On Mon, 2026-05-11 at 16:00 +0200, Joao Marcos Costa via
> > > > lists.openembedded.org wrote:
> > > > > Hello,
> > > > > 
> > > > > On 5/11/26 15:52, Quentin Schulz via lists.openembedded.org
> > > > > wrote:
> > > > > (...)
> > > > > > 
> > > > > > Not necessarily true as I don't think we build GCC for
> > > > > > native recipes
> > > > > > (and ovmf has a native variant), so it depends on the GCC
> > > > > > on the host
> > > > > > (unless you have uninative?). I don't know the autobuilder
> > > > > > infrastructure, e.g. whether we build patches on multiple
> > > > > > workers on
> > > > > > different distros to have a big GCC version test matrix.
> > > > > > 
> > > > > > But yes, building with a newer GCC will generally not make
> > > > > > warnings from
> > > > > > previous versions disappear and I'm hoping upstream has had
> > > > > > time to fix
> > > > > > warnings returned by GCC12 in the last 4 years :)
> > > > > > 
> > > > > > Cheers,
> > > > > > Quentin
> > > > > 
> > > > > Yep, my whole point is based on the the distros in
> > > > > SANITY_TESTED_DISTROS
> > > > > being recent enough to ship GCC > 12 :)
> > > > > 
> > > > > I should have made it explicit in my commit message.
> > > > 
> > > > I hate to say this but:
> > > > 
> > > > Alma/Centos/Rocky 8 have gcc 8
> > > > Debian 11 has gcc 10
> > > > 
> > > > and we don't use buildtools on debian 11.
> > > > 
> > > > I'm therefore not sure how you concluded that from
> > > > SANITY_TESTED_DISTROS.
> > > > 
> > > > Cheers,
> > > > 
> > > > Richard
> > > 
> > > Ah, my bad...
> > > 
> > >   From this list here:
> > > https://docs.yoctoproject.org/ref-manual/system-requirements.html#supported-linux-distributions
> > > 
> > > Considering the versions of Fedora and Ubuntu, I presumed the
> > > other
> > > distros were at least as recent (in terms of packages versions)
> > > as
> > > Fedora 39 (which ships GCC 13).
> > > 
> > > I will check the results in SWAT to see if this warnings pops up,
> > > but
> > > the commit message could use a rewording to address this point
> > > and also
> > > some questions raised by Quentin, so a v2 will be sent later in
> > > this week.
> > 
> > We currently support distros with gcc 10, I think that is clear.
> 
> It is clear, yes, but my point here is the -Wno-error=stringop-
> overflow 
> already being available upstream in the version of edk2 we currently 
> use, and - as per what I understood in their git history - the flag
> was 
> added for the very same reason we have it in the recipe.

Ok, that makes sense. 

Cheers,

Richard

Re: [OE-core] [PATCH 1/3] ovmf: simplify PACKAGECONFIG's default value

[Ross Burton]

On 11 May 2026, at 14:19, Quentin Schulz via lists.openembedded.org <quentin.schulz=cherry.de@lists.openembedded.org> wrote:
> 
>> -PACKAGECONFIG ??= ""
>> -PACKAGECONFIG += "${@bb.utils.filter('MACHINE_FEATURES', 'tpm', d)}"
>> -PACKAGECONFIG += "${@bb.utils.contains('MACHINE_FEATURES', 'tpm2', 'tpm', '', d)}"
>> +PACKAGECONFIG ?= "${@bb.utils.contains_any('MACHINE_FEATURES', 'tpm tpm2', 'tpm', '', d)}"
> 
> Just a heads up that this is *not* equivalent.
> 
> The use of ??= meant that any ?= (and ??=) parsed anywhere before that line is meant that it would set the default values, and then we would append to those default values tpm.
> 
> Now by merging those into a single ?=, a previous ?= will override this new ?= operator, meaning tpm won't make  it to the PACKAGECONFIG even if the MACHINE_FEATURES is set to tpm/tpm2. Also, an earlier ??= won't do anything anymore.
> 
> Whether that's an actual issue, I don't know, but you may break users.
> 
> Merging the two += into a single one would truly be equivalent.

The old value _was_ very un-idiomatic but the replacement is too.

However:

PACKAGECONFIG ??= "${@bb.utils.contains_any('MACHINE_FEATURES', 'tpm tpm2', 'tpm', '', d)}”

Is idiomatic and whilst a change of behaviour, it has the expected behaviour.  Can you use ??= and clarify that whilst this changes the behaviour in edge cases, what we prefer is consistency between recipes.

Ross

Re: [OE-core] [PATCH 1/3] ovmf: simplify PACKAGECONFIG's default value

[Joao Marcos Costa]

Hello, folks

On 5/14/26 12:57, Ross Burton wrote:
> On 11 May 2026, at 14:19, Quentin Schulz via lists.openembedded.org <quentin.schulz=cherry.de@lists.openembedded.org> wrote:
>>
>>> -PACKAGECONFIG ??= ""
>>> -PACKAGECONFIG += "${@bb.utils.filter('MACHINE_FEATURES', 'tpm', d)}"
>>> -PACKAGECONFIG += "${@bb.utils.contains('MACHINE_FEATURES', 'tpm2', 'tpm', '', d)}"
>>> +PACKAGECONFIG ?= "${@bb.utils.contains_any('MACHINE_FEATURES', 'tpm tpm2', 'tpm', '', d)}"
>>
>> Just a heads up that this is *not* equivalent.
>>
>> The use of ??= meant that any ?= (and ??=) parsed anywhere before that line is meant that it would set the default values, and then we would append to those default values tpm.
>>
>> Now by merging those into a single ?=, a previous ?= will override this new ?= operator, meaning tpm won't make  it to the PACKAGECONFIG even if the MACHINE_FEATURES is set to tpm/tpm2. Also, an earlier ??= won't do anything anymore.
>>
>> Whether that's an actual issue, I don't know, but you may break users.
>>
>> Merging the two += into a single one would truly be equivalent.
> 
> The old value _was_ very un-idiomatic but the replacement is too.
> 
> However:
> 
> PACKAGECONFIG ??= "${@bb.utils.contains_any('MACHINE_FEATURES', 'tpm tpm2', 'tpm', '', d)}”
> 
> Is idiomatic and whilst a change of behaviour, it has the expected behaviour.  Can you use ??= and clarify that whilst this changes the behaviour in edge cases, what we prefer is consistency between recipes.
> 
> Ross

I missed one of the "?", and playing with bitbake-getvar was leading to 
the same results, but yes, this needs to be fixed. I will send a v2 
fixing this and other slight issues with the commit message in another 
patch (the second one, IIRC).

That said, I'd still appreciate some feedback on the third patch with 
regards to Clang support (cc Richard and Khem). Thanks!

-- 
Best regards,
João Marcos Costa