public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: Randolph Sapp <rs@ti.com>
To: <changqing.li@windriver.com>,
	"Ricardo de Araujo (Salveti)" <ricardo.salveti@oss.qualcomm.com>,
	Randolph Sapp <rs@ti.com>
Cc: <raj.khem@gmail.com>, <openembedded-core@lists.openembedded.org>
Subject: Re: [oe-core][PATCH] bitbake.conf: remove DEBUG_PREFIX_MAP from TARGET_LDFLAGS
Date: Tue, 3 Feb 2026 14:05:55 -0600	[thread overview]
Message-ID: <DG5LI7KVRXQE.2N11NZEFI41AB@ti.com> (raw)
In-Reply-To: <be095942-3b0f-4d62-97ff-590e7b6fbfbd@windriver.com>

On Mon Feb 2, 2026 at 10:46 PM CST, Changqing Li via lists.openembedded.org wrote:
>
> 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 <rs@ti.com> 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 <rs@ti.com> 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
>>>>>> <raj.khem=gmail.com@lists.openembedded.org> wrote:
>>>>>>> On Tue, Jan 27, 2026 at 8:31 AM Randolph Sapp <rs@ti.com> 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 Changqing, the LTO + DEBUG_PREFIX_MAP is fine if we know ahead of time or
are setting that flag ourselves. Unfortunately some things like lxc force LTO
with meson project flags. Tricks like that makes things a little messy.

- Randolph


      reply	other threads:[~2026-02-03 20:06 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-22 19:50 [oe-core][PATCH] bitbake.conf: remove DEBUG_PREFIX_MAP from TARGET_LDFLAGS rs
2026-01-26  8:39 ` Changqing Li
2026-01-26 15:04   ` Tony Battersby
2026-01-26 20:50     ` Randolph Sapp
2026-01-27  2:49       ` Changqing Li
2026-01-27  6:12         ` Khem Raj
2026-01-27 16:31           ` Randolph Sapp
2026-01-27 16:50             ` Khem Raj
2026-01-29 23:45               ` Ricardo de Araujo (Salveti)
2026-01-30  0:15                 ` Randolph Sapp
2026-01-30 15:22                   ` Ricardo de Araujo (Salveti)
2026-01-31  1:52                     ` Randolph Sapp
2026-02-02 20:10                       ` Ricardo de Araujo (Salveti)
2026-02-03  4:46                         ` Changqing Li
2026-02-03 20:05                           ` Randolph Sapp [this message]

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=DG5LI7KVRXQE.2N11NZEFI41AB@ti.com \
    --to=rs@ti.com \
    --cc=changqing.li@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=raj.khem@gmail.com \
    --cc=ricardo.salveti@oss.qualcomm.com \
    /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