All of lore.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.