Re: [oe-core][PATCH] bitbake.conf: remove DEBUG_PREFIX_MAP from TARGET_LDFLAGS

[Changqing Li <changqing.li@windriver.com>]

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,
>
> Ricardo