[oe-core][PATCH 1/3] gtk4: upgrade 4.22.5 -> 4.24.0

[oe-core][PATCH 1/3] gtk4: upgrade 4.22.5 -> 4.24.0

[Markus Volk]

Needs glib-2.0 >= 2.89.3, which the 2.90.0 upgrade provides.

AI-Generated: Uses Claude Code (Claude Opus 5)
Signed-off-by: Markus Volk <f_l_k@t-online.de>
---
 meta/recipes-gnome/gtk+/{gtk4_4.22.5.bb => gtk4_4.24.0.bb} | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-gnome/gtk+/{gtk4_4.22.5.bb => gtk4_4.24.0.bb} (97%)

diff --git a/meta/recipes-gnome/gtk+/gtk4_4.22.5.bb b/meta/recipes-gnome/gtk+/gtk4_4.24.0.bb
similarity index 97%
rename from meta/recipes-gnome/gtk+/gtk4_4.22.5.bb
rename to meta/recipes-gnome/gtk+/gtk4_4.24.0.bb
index 5d7385d29a..8a350d44f2 100644
--- a/meta/recipes-gnome/gtk+/gtk4_4.22.5.bb
+++ b/meta/recipes-gnome/gtk+/gtk4_4.24.0.bb
@@ -33,7 +33,7 @@ LIC_FILES_CHKSUM = " \
     file://tests/testgtk.c;endline=25;md5=49d06770681b8322466b52ed19d29fb2 \
 "
 
-SRC_URI[archive.sha256sum] = "7fd725deb2cb3f8dc218ad862c5056ff8548f49d3b0e4081796e444c22d19686"
+SRC_URI[archive.sha256sum] = "28ba4ac1c04f86eac09b79a163cb163a4c2b54442d9f7eccc04679062a581044"
 
 S = "${UNPACKDIR}/${GNOMEBN}-${PV}"
 
-- 
2.55.0

[oe-core][PATCH 2/3] libadwaita: upgrade 1.9.3 -> 1.10.0

[Markus Volk]

Needs gtk4 >= 4.23.1 and glib-2.0 >= 2.89.3.

AI-Generated: Uses Claude Code (Claude Opus 5)
Signed-off-by: Markus Volk <f_l_k@t-online.de>
---
 .../libadwaita/{libadwaita_1.9.3.bb => libadwaita_1.10.0.bb}    | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-gnome/libadwaita/{libadwaita_1.9.3.bb => libadwaita_1.10.0.bb} (89%)

diff --git a/meta/recipes-gnome/libadwaita/libadwaita_1.9.3.bb b/meta/recipes-gnome/libadwaita/libadwaita_1.10.0.bb
similarity index 89%
rename from meta/recipes-gnome/libadwaita/libadwaita_1.9.3.bb
rename to meta/recipes-gnome/libadwaita/libadwaita_1.10.0.bb
index 4752147402..21c0395b84 100644
--- a/meta/recipes-gnome/libadwaita/libadwaita_1.9.3.bb
+++ b/meta/recipes-gnome/libadwaita/libadwaita_1.10.0.bb
@@ -12,7 +12,7 @@ DEPENDS = " \
 
 inherit gnomebase gobject-introspection gi-docgen vala features_check
 
-SRC_URI[archive.sha256sum] = "fc59b37028fe0126308e7b805d2f6e4e80227080a1797715e5e6286b8111e723"
+SRC_URI[archive.sha256sum] = "b1bf56239269d101a6391ad4553c910eff9cc6170b803916405477ef60a66c84"
 
 ANY_OF_DISTRO_FEATURES = "${GTK3DISTROFEATURES}"
 REQUIRED_DISTRO_FEATURES = "opengl"
-- 
2.55.0

[oe-core][PATCH 3/3] adwaita-icon-theme: upgrade 50.0 -> 51.0

[Markus Volk]

AI-Generated: Uses Claude Code (Claude Opus 5)
Signed-off-by: Markus Volk <f_l_k@t-online.de>
---
 .../{adwaita-icon-theme_50.0.bb => adwaita-icon-theme_51.0.bb}  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-gnome/gnome/{adwaita-icon-theme_50.0.bb => adwaita-icon-theme_51.0.bb} (91%)

diff --git a/meta/recipes-gnome/gnome/adwaita-icon-theme_50.0.bb b/meta/recipes-gnome/gnome/adwaita-icon-theme_51.0.bb
similarity index 91%
rename from meta/recipes-gnome/gnome/adwaita-icon-theme_50.0.bb
rename to meta/recipes-gnome/gnome/adwaita-icon-theme_51.0.bb
index b0dc59353d..78dbe000ee 100644
--- a/meta/recipes-gnome/gnome/adwaita-icon-theme_50.0.bb
+++ b/meta/recipes-gnome/gnome/adwaita-icon-theme_51.0.bb
@@ -12,7 +12,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=c84cac88e46fc07647ea07e6c24eeb7c \
 
 inherit gnomebase allarch gtk-icon-cache
 
-SRC_URI[archive.sha256sum] = "fac6e0401fca714780561a081b8f7e27c3bc1db34ebda4da175081f26b24d460"
+SRC_URI[archive.sha256sum] = "ba561cf3c96305a47179fa5605856ad695c9238ea07f7093aebd9ba80c4e323b"
 
 DEPENDS += "librsvg-native"
 
-- 
2.55.0

Re: [oe-core][PATCH 3/3] adwaita-icon-theme: upgrade 50.0 -> 51.0

[Richard Purdie]

Hi Markus,

In the patch review call, whilst I was probably slightly in favour, the
general suggestion was to hold off on gnome 51 until after the release.
We do have quite a few 51 upgrades coming in, both here and in meta-oe
and I want check we're all on the same page. Should we move to 51 for
this release or not?

I'm suspecting we probably do want at least the glib upgrade?

Copying Ross.

Cheers,

Richard


On Wed, 2026-09-16 at 07:53 +0200, Markus Volk via lists.openembedded.org wrote:
> AI-Generated: Uses Claude Code (Claude Opus 5)
> Signed-off-by: Markus Volk <f_l_k@t-online.de>
> ---
>  .../{adwaita-icon-theme_50.0.bb => adwaita-icon-theme_51.0.bb}  | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>  rename meta/recipes-gnome/gnome/{adwaita-icon-theme_50.0.bb => adwaita-icon-theme_51.0.bb} (91%)
> 
> diff --git a/meta/recipes-gnome/gnome/adwaita-icon-theme_50.0.bb b/meta/recipes-gnome/gnome/adwaita-icon-theme_51.0.bb
> similarity index 91%
> rename from meta/recipes-gnome/gnome/adwaita-icon-theme_50.0.bb
> rename to meta/recipes-gnome/gnome/adwaita-icon-theme_51.0.bb
> index b0dc59353d..78dbe000ee 100644
> --- a/meta/recipes-gnome/gnome/adwaita-icon-theme_50.0.bb
> +++ b/meta/recipes-gnome/gnome/adwaita-icon-theme_51.0.bb
> @@ -12,7 +12,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=c84cac88e46fc07647ea07e6c24eeb7c \
>  
>  inherit gnomebase allarch gtk-icon-cache
>  
> -SRC_URI[archive.sha256sum] = "fac6e0401fca714780561a081b8f7e27c3bc1db34ebda4da175081f26b24d460"
> +SRC_URI[archive.sha256sum] = "ba561cf3c96305a47179fa5605856ad695c9238ea07f7093aebd9ba80c4e323b"
>  
>  DEPENDS += "librsvg-native"

Re: [oe-core][PATCH 3/3] adwaita-icon-theme: upgrade 50.0 -> 51.0

[Markus Volk]

[-- Attachment #1: Type: text/plain, Size: 532 bytes --]

Hi Richard,

I created the GNOME-51 recipes to verify the basic functionality and 
test it in a runtime environment.
The only really annoying issue I've noticed so far is a segfault in 
gnome-keyring-51, which I've already
been able to fix locally. I don’t want to cause any confusion, and if 
the general consensus is that the
GNOME update should only be added after the release, I’m fine with 
that. However, if glib-2.0, gtk4
and libadwaita do make it into the release, I would personally consider 
that a benefit.


[-- Attachment #2: Type: text/html, Size: 642 bytes --]

Re: [oe-core][PATCH 3/3] adwaita-icon-theme: upgrade 50.0 -> 51.0

[Ross Burton]

On 16 Sep 2026, at 09:41, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> 
> Hi Markus,
> 
> In the patch review call, whilst I was probably slightly in favour, the
> general suggestion was to hold off on gnome 51 until after the release.
> We do have quite a few 51 upgrades coming in, both here and in meta-oe
> and I want check we're all on the same page. Should we move to 51 for
> this release or not?
> 
> I'm suspecting we probably do want at least the glib upgrade?

GLib especially is fine. GTK and associated recipes, probably good. Anything higher up the stack into what we’d call GNOME instead of GTK I think we hold off because really there needs to be a concerted upgrade at once, and GNOME is currently split between oe-core and meta-gnome (because of epiphany).

Ross

Re: [oe-core][PATCH 1/3] gtk4: upgrade 4.22.5 -> 4.24.0

[Antonin Godard]

Hi,

On Wed Sep 16, 2026 at 7:53 AM CEST, Markus Volk via lists.openembedded.org wrote:
> Needs glib-2.0 >= 2.89.3, which the 2.90.0 upgrade provides.
>
> AI-Generated: Uses Claude Code (Claude Opus 5)
> Signed-off-by: Markus Volk <f_l_k@t-online.de>
> ---
>  meta/recipes-gnome/gtk+/{gtk4_4.22.5.bb => gtk4_4.24.0.bb} | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>  rename meta/recipes-gnome/gtk+/{gtk4_4.22.5.bb => gtk4_4.24.0.bb} (97%)
>
> diff --git a/meta/recipes-gnome/gtk+/gtk4_4.22.5.bb b/meta/recipes-gnome/gtk+/gtk4_4.24.0.bb
> similarity index 97%
> rename from meta/recipes-gnome/gtk+/gtk4_4.22.5.bb
> rename to meta/recipes-gnome/gtk+/gtk4_4.24.0.bb
> index 5d7385d29a..8a350d44f2 100644
> --- a/meta/recipes-gnome/gtk+/gtk4_4.22.5.bb
> +++ b/meta/recipes-gnome/gtk+/gtk4_4.24.0.bb
> @@ -33,7 +33,7 @@ LIC_FILES_CHKSUM = " \
>      file://tests/testgtk.c;endline=25;md5=49d06770681b8322466b52ed19d29fb2 \
>  "
>  
> -SRC_URI[archive.sha256sum] = "7fd725deb2cb3f8dc218ad862c5056ff8548f49d3b0e4081796e444c22d19686"
> +SRC_URI[archive.sha256sum] = "28ba4ac1c04f86eac09b79a163cb163a4c2b54442d9f7eccc04679062a581044"
>  
>  S = "${UNPACKDIR}/${GNOMEBN}-${PV}"
>  

I think your patch triggers the following error:

ERROR: gtk4-4.24.0-r0 do_package_qa: QA Issue: File /usr/src/debug/gtk4/4.24.0/gtk/svg/libgtk_svg.a.p/gtk_svg-unity0.c in package gtk4-src contains reference to TMPDIR [buildpaths]
ERROR: gtk4-4.24.0-r0 do_package_qa: QA Issue: File /usr/src/debug/gtk4/4.24.0/gtk/svg/libgtk_svg.a.p/gtk_svg-unity0.c in package gtk4-src contains a reference to the build host HOME directory. If upstream hardcodes a directory path that matches your home, you can set OEQA_BUILDPATHS_SKIP = "/srv/pokybuild" in the recipe. [buildpaths]

Full log: https://autobuilder.yoctoproject.org/valkyrie/api/v2/logs/8949458/raw_inline
Parent build: https://autobuilder.yoctoproject.org/valkyrie/#/builders/10/builds/4634

Not sure we are going to merge this yet after reading the thread, but you might
want to look into it.

Antonin

Re: [oe-core][PATCH 1/3] gtk4: upgrade 4.22.5 -> 4.24.0

[Markus Volk]

[-- Attachment #1: Type: text/plain, Size: 932 bytes --]

For some reason the unity file doesn't get installed in my gtk4-src 
package so I didn' hit this issue.
Maybe this should be done in meson.bbclass if more projects use this 
mechanism?

On Wed, Sep 16 2026 at 13:43:25 +02:00:00, Antonin Godard via 
lists.openembedded.org 
<antonin.godard=bootlin.com@lists.openembedded.org> wrote:
> I think your patch triggers the following error:
> 
> ERROR: gtk4-4.24.0-r0 do_package_qa: QA Issue: File 
> /usr/src/debug/gtk4/4.24.0/gtk/svg/libgtk_svg.a.p/gtk_svg-unity0.c in 
> package gtk4-src contains reference to TMPDIR [buildpaths]
> ERROR: gtk4-4.24.0-r0 do_package_qa: QA Issue: File 
> /usr/src/debug/gtk4/4.24.0/gtk/svg/libgtk_svg.a.p/gtk_svg-unity0.c in 
> package gtk4-src contains a reference to the build host HOME 
> directory. If upstream hardcodes a directory path that matches your 
> home, you can set OEQA_BUILDPATHS_SKIP = "/srv/pokybuild" in the 
> recipe. [buildpaths]




[-- Attachment #2: Type: text/html, Size: 1107 bytes --]

Re: [oe-core][PATCH 1/3] gtk4: upgrade 4.22.5 -> 4.24.0

[Ross Burton]

On 16 Sep 2026, at 12:43, Antonin Godard via lists.openembedded.org <antonin.godard=bootlin.com@lists.openembedded.org> wrote:
> 
> ERROR: gtk4-4.24.0-r0 do_package_qa: QA Issue: File /usr/src/debug/gtk4/4.24.0/gtk/svg/libgtk_svg.a.p/gtk_svg-unity0.c in package gtk4-src contains reference to TMPDIR [buildpaths]
> ERROR: gtk4-4.24.0-r0 do_package_qa: QA Issue: File /usr/src/debug/gtk4/4.24.0/gtk/svg/libgtk_svg.a.p/gtk_svg-unity0.c in package gtk4-src contains a reference to the build host HOME directory. If upstream hardcodes a directory path that matches your home, you can set OEQA_BUILDPATHS_SKIP = "/srv/pokybuild" in the recipe. [buildpaths]
> 
> Full log: https://autobuilder.yoctoproject.org/valkyrie/api/v2/logs/8949458/raw_inline
> Parent build: https://autobuilder.yoctoproject.org/valkyrie/#/builders/10/builds/4634

I know that there’s a v2 with a workaround for this, but I was curious where the root of the failure is and if this is actually a problem with meson.  However, I can’t reproduce it locally, in fact there is no libgtk_svg.a.p/ directory in my -src package at all.

Do either of you have any idea what could have been triggering this?

Cheers,
Ross

Re: [oe-core][PATCH 1/3] gtk4: upgrade 4.22.5 -> 4.24.0

[Markus Volk]

[-- Attachment #1: Type: text/plain, Size: 4435 bytes --]

That's what claude "thinks" about the issue:
The root cause is not in meson. It is the combination of a gcc configure
bug that only hits 32-bit ARM and a weakness in dwarfsrcfiles that hides
the problem everywhere else. That is why only beaglebone-alt failed and
why neither of us can reproduce it on x86-64.

What is the same on every architecture:

meson passes the unity file to the compiler by its relative path,
gtk/svg/libgtk_svg.a.p/gtk_svg-unity0.c. Because gcc.bbclass adds
-fcanon-prefix-map, gcc canonicalises it and stores the remapped absolute
path as the CU name:

  DW_AT_name     :
/usr/src/debug/gtk4/4.24.0/gtk/svg/libgtk_svg.a.p/gtk_svg-unity0.c
  DW_AT_comp_dir : /usr/src/debug/gtk4/4.24.0

dwarfsrcfiles unconditionally prints comp_dir + "/" + name for the CU, so
for an absolute name it produces a doubled path:


/usr/src/debug/gtk4/4.24.0//usr/src/debug/gtk4/4.24.0/gtk/svg/libgtk_svg.a.p/gtk_svg-unity0.c

copydebugsources strips the prefix, is left with an absolute path, and
cpio cannot find that below ${B}. So via the CU name the file is never
copied. That is why there is no libgtk_svg.a.p/ in your -src package.

What is different on ARM:

Whether the file is copied anyway depends on the line table. I built a
gcc-cross-arm and compiled a minimal unity file with both toolchains and
the same flags:

  x86-64: DWARF 5 line table built by gas, unity file only as entry 0,
          which dwarfsrcfiles skips (its loop starts at 1)
  arm:    DWARF 3 line table built by gas, unity file as entry 1,
          listed by dwarfsrcfiles as
          /usr/src/debug/gtk4/4.24.0/gtk/svg/libgtk_svg.a.p/gtk_svg-unity0.c

With that path copydebugsources copies the file from ${B} into -src, and
it carries the #include lines with the absolute build directory, hence
the buildpaths QA error.

The reason is gcc's configure. On the arm cross compiler
HAVE_AS_WORKING_DWARF_N_FLAG is not defined, on x86-64 and aarch64 it is.
The preceding check "--gdwarf-4 with the APP marker" uses a hard-coded
"ret" instruction instead of $insn, which does not assemble on ARM:

  checking assembler for --gdwarf-4 with the APP marker
  conftest.s:14: Error: bad instruction `ret'

So the real check is never run, gas is not passed --gdwarf-5, and the
whole ".file 0" logic in dwarf2out.cc is disabled on 32-bit ARM. gcc then
emits the main file as ".file 1", which is exactly what dwarfsrcfiles
picks up.

So: unity builds by nature generate a source file with absolute include
paths in the build directory, and OE copies sources referenced from the
debug info out of ${B} into -src. That it does not show up on x86-64 is
an accident of dwarfsrcfiles, not proof that it is fine. Fixing
dwarfsrcfiles to not prepend comp_dir to absolute CU names would make the
error reproducible on every architecture. The workaround in v2 is
therefore justified; a more general fix would be to apply the prefix
rewriting to files copied out of ${B} in copydebugsources. The gcc
configure bug is worth reporting upstream separately.



Am Fr., 18. Sept. 2026 um 13:19 Uhr schrieb Ross Burton <Ross.Burton@arm.com
>:

> On 16 Sep 2026, at 12:43, Antonin Godard via lists.openembedded.org
> <antonin.godard=bootlin.com@lists.openembedded.org> wrote:
> >
> > ERROR: gtk4-4.24.0-r0 do_package_qa: QA Issue: File
> /usr/src/debug/gtk4/4.24.0/gtk/svg/libgtk_svg.a.p/gtk_svg-unity0.c in
> package gtk4-src contains reference to TMPDIR [buildpaths]
> > ERROR: gtk4-4.24.0-r0 do_package_qa: QA Issue: File
> /usr/src/debug/gtk4/4.24.0/gtk/svg/libgtk_svg.a.p/gtk_svg-unity0.c in
> package gtk4-src contains a reference to the build host HOME directory. If
> upstream hardcodes a directory path that matches your home, you can set
> OEQA_BUILDPATHS_SKIP = "/srv/pokybuild" in the recipe. [buildpaths]
> >
> > Full log:
> https://autobuilder.yoctoproject.org/valkyrie/api/v2/logs/8949458/raw_inline
> > Parent build:
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/10/builds/4634
>
> I know that there’s a v2 with a workaround for this, but I was curious
> where the root of the failure is and if this is actually a problem with
> meson.  However, I can’t reproduce it locally, in fact there is no
> libgtk_svg.a.p/ directory in my -src package at all.
>
> Do either of you have any idea what could have been triggering this?
>
> Cheers,
> Ross

[-- Attachment #2: Type: text/html, Size: 5385 bytes --]

Re: [oe-core][PATCH 1/3] gtk4: upgrade 4.22.5 -> 4.24.0

[Ross Burton]

On 18 Sep 2026, at 13:18, Markus Volk <mrksvolk@googlemail.com> wrote:
> 
> That's what claude "thinks" about the issue:

Hmm.

> The root cause is not in meson. It is the combination of a gcc configure
> bug that only hits 32-bit ARM and a weakness in dwarfsrcfiles that hides
> the problem everywhere else. That is why only beaglebone-alt failed and
> why neither of us can reproduce it on x86-64.

Sounds like we’re fixing the wrong place.

> What is the same on every architecture:
> 
> meson passes the unity file to the compiler by its relative path,
> gtk/svg/libgtk_svg.a.p/gtk_svg-unity0.c. Because gcc.bbclass adds
> -fcanon-prefix-map, gcc canonicalises it and stores the remapped absolute
> path as the CU name:
> 
>   DW_AT_name     : /usr/src/debug/gtk4/4.24.0/gtk/svg/libgtk_svg.a.p/gtk_svg-unity0.c
>   DW_AT_comp_dir : /usr/src/debug/gtk4/4.24.0
> 
> dwarfsrcfiles unconditionally prints comp_dir + "/" + name for the CU, so
> for an absolute name it produces a doubled path:
>   /usr/src/debug/gtk4/4.24.0//usr/src/debug/gtk4/4.24.0/gtk/svg/libgtk_svg.a.p/gtk_svg-unity0.c

Bug in dwarfsrcfiles.  binutils has a tool now to do this (eu-srcfiles), so I’m actually testing a build with that instead.

> What is different on ARM:
> 
> Whether the file is copied anyway depends on the line table. I built a
> gcc-cross-arm and compiled a minimal unity file with both toolchains and
> the same flags:
> 
>   x86-64: DWARF 5 line table built by gas, unity file only as entry 0,
>           which dwarfsrcfiles skips (its loop starts at 1)
>   arm:    DWARF 3 line table built by gas, unity file as entry 1,
>           listed by dwarfsrcfiles as
>           /usr/src/debug/gtk4/4.24.0/gtk/svg/libgtk_svg.a.p/gtk_svg-unity0.c

So is index 0 special? I don’t understand what’s happening here. I note that eu-srcfiles and dwarfsrcfiles output slightly different things here, specifically the unity file itself isn’t dumped by eu-srcfiles.

> The reason is gcc's configure. On the arm cross compiler
> HAVE_AS_WORKING_DWARF_N_FLAG is not defined, on x86-64 and aarch64 it is.
> The preceding check "--gdwarf-4 with the APP marker" uses a hard-coded
> "ret" instruction instead of $insn, which does not assemble on ARM:
> 
>   checking assembler for --gdwarf-4 with the APP marker
>   conftest.s:14: Error: bad instruction `ret'
> 
> So the real check is never run, gas is not passed --gdwarf-5, and the
> whole ".file 0" logic in dwarf2out.cc is disabled on 32-bit ARM. gcc then
> emits the main file as ".file 1", which is exactly what dwarfsrcfiles
> picks up.

The ‘ret’ bug I’ve discussed with GCC, verified that s/ret/$insn/ is a good fix, and we can incorporate that.

There’s multiple bugs here and working around them in GTK isn’t the best fix.

Ross

Re: [oe-core][PATCH 1/3] gtk4: upgrade 4.22.5 -> 4.24.0

[Ross Burton]

On 18 Sep 2026, at 17:17, Ross Burton <Ross.Burton@arm.com> wrote:
>> The root cause is not in meson. It is the combination of a gcc configure
>> bug that only hits 32-bit ARM and a weakness in dwarfsrcfiles that hides
>> the problem everywhere else. That is why only beaglebone-alt failed and
>> why neither of us can reproduce it on x86-64.
> 
> Sounds like we’re fixing the wrong place.

I’ve just sent an oe-core patch to backport a now-upstream gcc fix for this.

>> dwarfsrcfiles unconditionally prints comp_dir + "/" + name for the CU, so
>> for an absolute name it produces a doubled path:
>>  /usr/src/debug/gtk4/4.24.0//usr/src/debug/gtk4/4.24.0/gtk/svg/libgtk_svg.a.p/gtk_svg-unity0.c
> 
> Bug in dwarfsrcfiles.  binutils has a tool now to do this (eu-srcfiles), so I’m actually testing a build with that instead.

My test branch works but we can merge that post-release, as this is entirely unrelated to the issue.

>> What is different on ARM:
>> 
>> Whether the file is copied anyway depends on the line table. I built a
>> gcc-cross-arm and compiled a minimal unity file with both toolchains and
>> the same flags:
>> 
>>  x86-64: DWARF 5 line table built by gas, unity file only as entry 0,
>>          which dwarfsrcfiles skips (its loop starts at 1)
>>  arm:    DWARF 3 line table built by gas, unity file as entry 1,
>>          listed by dwarfsrcfiles as
>>          /usr/src/debug/gtk4/4.24.0/gtk/svg/libgtk_svg.a.p/gtk_svg-unity0.c
> 
> So is index 0 special? I don’t understand what’s happening here. I note that eu-srcfiles and dwarfsrcfiles output slightly different things here, specifically the unity file itself isn’t dumped by eu-srcfiles.

The actual reproducer is when a binary is built with dwarf5 data _and_ the source file doesn’t actually have any symbols, it doesn’t appear in the source file list.  I’ve filed a bug with elfutils (https://sourceware.org/bugzilla/show_bug.cgi?id=34666) for this edge case.  As the file has no definitions it’s not really a problem that it doesn’t get included in our debug sources file.

So, when the gcc fix is merged, we can take v1 of this upgrade without the workaround.

Ross