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 <[email protected]
>:
> On 16 Sep 2026, at 12:43, Antonin Godard via lists.openembedded.org
> <[email protected]> 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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#246235):
https://lists.openembedded.org/g/openembedded-core/message/246235
Mute This Topic: https://lists.openembedded.org/mt/121274837/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
