public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
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 --]

  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