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

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Wed, 2026-03-25 at 09:09 -0400, Patrick Williams wrote:
> 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.

Ok, now I understand. Thanks for making that clear.

> > 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).

Correct, unfortunately we don't. Adding one would mean having people
willing/able to fix bugs in that too though.

> 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/

I agree it should be in the lto config and I am happy to take that bit.
Equally, if we just bandaid this everywhere, people will continue to
ignore the issue and the bug will remain unsolved.

Having to pass huge linking commands around when they're not supposed
to be needed is pretty poor as well and breaks other things like go, as
you noticed.

Cheers,

Richard