Re: [OE-core] [PATCH] gcc: fix buildpaths QA with LTO

[Patrick Williams <patrick@stwcx.xyz>]

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

On Wed, Mar 25, 2026 at 12:53:28PM +0000, Richard Purdie wrote:
> On Wed, 2026-03-25 at 08:44 -0400, Patrick Williams wrote:
> > 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
> 
> My question still stands though - why don't we see this with systemd or
> libpam in OE-Core?

Because you do not enable LTO on those.

> You're asserting we need to add this to our default config as the
> output is broken. We don't see those failures anywhere in our testing
> (which definitely includes systemd).
> 
> Are you passing specific config to systemd or libpam to enable lto?

Yes, via a global EXTRA_OEMESON I pointed to above.  I only referred to
those because they are packages you have that can easily show this
symptom.

> I believe that if this breaks when you set certain configs, these
> workaround belong with those configs.

Ok.  We'll just keep it downstream if that's what you want.

I pointed to [1].  I do think this should at least be included in lto.inc
because otherwise lto.inc is similarly broke for everyone.  I'm guessing
you don't have an upstream test that enables lto.inc (yet).

I will argue it is a really bad experience for people though to _not_
have this in the default config.  It took me about 4 hours to track down
what was causing buildpath issues in previously working packages when
upgrading the OE-Core base, including tracking down the underlying gcc
bug.

[1]: https://lore.kernel.org/openembedded-core/20260204052638.284617-1-changqing.li@windriver.com/

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 870 bytes --]