On Wed, Mar 25, 2026 at 12:34:52PM +0000, Richard Purdie wrote:
> > > With GCC 15.2 this can be noticed by setting many meson-built packages,
> > > such as systemd, with:
> > > 
> > >     EXTRA_OEMESON:append:class-target = " -Db_lto=true"
> > > 
...
> 
> We're not seeing the error with OE-Core today in any of our automated
> testing. Reading the above, it implies that we should see some kind of
> failure with some components auto-selecting it? Something therefore
> isn't adding up.

I tried to give recreate instructions here.  OE-Core doesn't actually do
this so you won't see it unless you enable it.

OpenBMC has a large number of meson-built packages which are generally
safe to enable LTO on (but in the past I've ran into issues with other
packages not building with LTO; now with lto.inc I should revisit this).

We have a global enable for all meson packages:
    https://github.com/openbmc/openbmc/blob/47d900012a93d79ab536ca172fc01cd89645a0d8/meta-phosphor/conf/distro/include/phosphor-defaults.inc#L153

When I upgraded to an OE core that had 1797741aad02b8bf429fac4b81e30cdda64b5448,
almost all of our packages started failing with buildpaths.  I was able
to track it down to this problem.  systemd and libpam are two that are
OE or meta-openembedded packages that I saw fail this way, so I gave
systemd as a clear example.  Like I said, we have a lot of packages in
meta-phosphor[1] that we have enabled LTO on and they're all failing
with buildpaths QA failures without a change to pass along
DEBUG_PREFIX_MAP.

If it helps, I can upload the objdump content.  There was DWARF data
being inserted by the GIMPLE intermediate which wasn't being stripped by
the linker that had my build path in it.

[1]: https://github.com/openbmc/openbmc/tree/master/meta-phosphor

-- 
Patrick Williams