On 2/3/26 04:10, Ricardo de Araujo (Salveti) wrote:
CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know
the content is safe.
On Fri, Jan 30, 2026 at 10:52 PM Randolph Sapp <[email protected]> wrote:
On Fri Jan 30, 2026 at 9:22 AM CST, Ricardo de Araujo (Salveti) wrote:
On Thu, Jan 29, 2026 at 9:15 PM Randolph Sapp <[email protected]> wrote:
On Thu Jan 29, 2026 at 5:45 PM CST, Ricardo Salveti via lists.openembedded.org
wrote:
On Tue, Jan 27, 2026 at 1:50 PM Khem Raj via lists.openembedded.org
<[email protected]> wrote:
On Tue, Jan 27, 2026 at 8:31 AM Randolph Sapp <[email protected]> wrote:
On Tue Jan 27, 2026 at 12:12 AM CST, Khem Raj via lists.openembedded.org wrote:
I am seeing some additional diagnostics see
https://autobuilder.yoctoproject.org/valkyrie/api/v2/logs/5119153/raw_inline
I wonder if this is related.
Man, the mail clients are having fun with this thread.
Yeah, I'm able to reproduce that issue locally now. Not sure why it's this
package subset that's acting up, but it is directly related to the LDFLAGS
change unfortunately.
I think this is exposing the underlying issue in packages perhaps because they
are
not respecting CFLAGS and when it's gone from LDFLAGS the mapping related
flags go missing. I have a local patch to fix memstat e.g in master-next, all
failures
perhaps need to be looked into one by one and passed cflags from OE env which
might have been missed thus far.
Just noticed a similar failure with lxc (meta-virtualization), but
while the prefix-map options are provided via CFLAGS, it only works
when provided via LDFLAGS, probably due LTO (enabled by default by
lxc).
Patch available at
https://lists.yoctoproject.org/g/meta-virtualization/message/9553
I guess recipes forcing LTO will probably have similar issues.
Ran a test locally. Looking at the do_compile log there are actually several
compilation steps that do not have the macro prefixes passed as cc arguments.
That LTO bug has actually been addressed, it's just as Khem Raj pointed out,
sometimes CFLAGS is ignored and passing the prefixes with LDFLAGS was masking
that problem.
I did look into one of the binaries and it was built with the right
cflags options, but didn't investigate too much.
I can also confirm that it works fine after disabling LTO, that is why
I think it could be related to it.
Oh boy. Looking into this more today, spending plenty of time trying to make
sure it wasn't meson or some other argument combination causing issues, I
stumbled upon this thread [1]. They report the same issue with debug-prefixes,
but they also cite potentially package dependent behavior with LTO. There are
quite a few open threads about LTO behavior in general that are concerning.
Maybe this should be reverted and the alternative solution for cgo binary
reproducibility should be taken instead [2]? I don't really have the resources
to start on compiler development at the moment.
Right, it might be indeed better to revert for now as we will probably
face similar LTO issues with multiple recipes and layers, since the
bug is still valid upstream.
I did a world build with this patch + LTO enabled with our distro,
there are many failures, and it should be related to
this change. I did not check them all one by one, just check some of
them. Eg: cups(oe-core)
Maybe we can only append DEBUG_PREFIX_MAP in TARGET_LDFLAGS when LTO
enabled. I will send a patch for this later.
So we don't need to revert this change, and but we also need to take
the following commit:
https://lists.openembedded.org/g/openembedded-core/message/230059
Regards
Changqing
Thanks,
Ricardo
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#230418):
https://lists.openembedded.org/g/openembedded-core/message/230418
Mute This Topic: https://lists.openembedded.org/mt/117408334/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
