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

[Randolph Sapp <rs@ti.com>]

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

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.

Curious what others have to say, as there seems to be no clean way out right
now.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109805
[2] https://lists.openembedded.org/g/openembedded-core/message/230059

- Randolph