From: Patrick Williams <patrick@stwcx.xyz>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] gcc: fix buildpaths QA with LTO
Date: Wed, 25 Mar 2026 08:44:00 -0400 [thread overview]
Message-ID: <acPYkLXfOoJmv2lm@heinlein> (raw)
In-Reply-To: <9a222b692f97515655dd8dad792246068410d660.camel@linuxfoundation.org>
[-- Attachment #1: Type: text/plain, Size: 1844 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
next prev parent reply other threads:[~2026-03-25 12:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-25 11:39 [PATCH] gcc: fix buildpaths QA with LTO Patrick Williams
2026-03-25 11:46 ` Patrick Williams
2026-03-25 12:34 ` [OE-core] " Richard Purdie
2026-03-25 12:44 ` Patrick Williams [this message]
2026-03-25 12:53 ` Richard Purdie
2026-03-25 13:09 ` Patrick Williams
2026-03-25 14:25 ` Richard Purdie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=acPYkLXfOoJmv2lm@heinlein \
--to=patrick@stwcx.xyz \
--cc=openembedded-core@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox