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/[email protected]/ -- Patrick Williams
signature.asc
Description: PGP signature
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#233909): https://lists.openembedded.org/g/openembedded-core/message/233909 Mute This Topic: https://lists.openembedded.org/mt/118499279/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
