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

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

[rs]

From: Randolph Sapp <rs@ti.com>

Now that the previous bug affecting binary reproducibility has been
addressed [1], we can revert this patch. This will resolve issues with
cgo applications becoming unreprodcible.

Currently go considers link arguments to be sacred, meaning any change
should produce a different binary output. They ensure this by baking
link arguments into the intermediary output, changing the content ID of
that step. As such, the marco prefixes inadvertently end up adding build
paths to the output binary instead of removing them if they are passed
as link arguments to cgo applications.

These paths are later stripped out again, but at this point the content
ID of the dependency has changed and thus the build ID of the end
application will be affected by the cascade of hash changes. See the
upstream bug for more information [2].

This reverts commit fddaecc88979967d0e00e2fafdbaaabec030da9f.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101473
[2] https://github.com/golang/go/issues/77218

Signed-off-by: Randolph Sapp <rs@ti.com>
---

This resolves the previously reported emptty issues:
https://lists.openembedded.org/g/openembedded-core/message/228549

 meta/conf/bitbake.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 88f4d0df69..da873c3f4e 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -634,7 +634,7 @@ TARGET_LINK_HASH_STYLE ?= "${@['-Wl,--hash-style=gnu',''][d.getVar('LINKER_HASH_
 ASNEEDED ?= "-Wl,--as-needed"
 
 export LDFLAGS = "${TARGET_LDFLAGS}"
-TARGET_LDFLAGS = "-Wl,-O1 ${TARGET_LINK_HASH_STYLE} ${ASNEEDED} ${DEBUG_PREFIX_MAP}"
+TARGET_LDFLAGS = "-Wl,-O1 ${TARGET_LINK_HASH_STYLE} ${ASNEEDED}"
 # mips does not support GNU hash style therefore we override
 LINKER_HASH_STYLE:mipsarch:libc-musl = "sysv"
 
-- 
2.52.0

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

[Changqing Li]

[-- Attachment #1: Type: text/plain, Size: 3422 bytes --]


On 1/23/26 03:50, Randolph Sapp via lists.openembedded.org 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.
>
> From: Randolph Sapp<rs@ti.com>
>
> Now that the previous bug affecting binary reproducibility has been
> addressed [1], we can revert this patch. This will resolve issues with
> cgo applications becoming unreprodcible.
>
> Currently go considers link arguments to be sacred, meaning any change
> should produce a different binary output. They ensure this by baking
> link arguments into the intermediary output, changing the content ID of
> that step. As such, the marco prefixes inadvertently end up adding build
> paths to the output binary instead of removing them if they are passed
> as link arguments to cgo applications.
>
> These paths are later stripped out again, but at this point the content
> ID of the dependency has changed and thus the build ID of the end
> application will be affected by the cascade of hash changes. See the
> upstream bug for more information [2].
>
> This reverts commit fddaecc88979967d0e00e2fafdbaaabec030da9f.
>
> [1]https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101473
> [2]https://github.com/golang/go/issues/77218
>
> Signed-off-by: Randolph Sapp<rs@ti.com>
> ---
>
> This resolves the previously reported emptty issues:
> https://lists.openembedded.org/g/openembedded-core/message/228549
>
>   meta/conf/bitbake.conf | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index 88f4d0df69..da873c3f4e 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -634,7 +634,7 @@ TARGET_LINK_HASH_STYLE ?="${@['-Wl,--hash-style=gnu',''][d.getVar('LINKER_HASH_ ASNEEDED ?= "-Wl,--as-needed"
>
>   export LDFLAGS = "${TARGET_LDFLAGS}"
> -TARGET_LDFLAGS = "-Wl,-O1 ${TARGET_LINK_HASH_STYLE} ${ASNEEDED} ${DEBUG_PREFIX_MAP}"
> +TARGET_LDFLAGS = "-Wl,-O1 ${TARGET_LINK_HASH_STYLE} ${ASNEEDED}"

Hi,

After check the related gcc bug and yocto bug,  gcc bug comments 21 
([1])  and yocto bug comments 13 ([2]),

my understanding is that,  when lto is enabled,  even with gcc fix [3],  
we still need DEBUG_PREFIX_MAP in LDFLAGS

to make bin reproducible. Also seems Tony's commit [4] is after gcc fix [3].

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101473#c21

[2] https://bugzilla.yoctoproject.org/show_bug.cgi?id=14481#c13

[3] https://gcc.gnu.org/g:7cc2df084b7977653a9b59cbc34a9ad500ae619c

[4] 
https://git.openembedded.org/openembedded-core/commit/?id=fddaecc88979967d0e00e2fafdbaaabec030da9f


@Tony, @Randolph, Could please correct me if my understanding is not 
right, Thanks.

//Changqing

>   # mips does not support GNU hash style therefore we override
>   LINKER_HASH_STYLE:mipsarch:libc-musl = "sysv"
>
> --
> 2.52.0
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#229857):https://lists.openembedded.org/g/openembedded-core/message/229857
> Mute This Topic:https://lists.openembedded.org/mt/117408334/3616873
> Group Owner:openembedded-core+owner@lists.openembedded.org
> Unsubscribe:https://lists.openembedded.org/g/openembedded-core/unsub [changqing.li@windriver.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

[-- Attachment #2: Type: text/html, Size: 5898 bytes --]

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

[Tony Battersby]

On 1/26/26 03:39, Changqing Li wrote:
>
>
> On 1/23/26 03:50, Randolph Sapp via lists.openembedded.org 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.
>>
>> From: Randolph Sapp <rs@ti.com>
>>
>> Now that the previous bug affecting binary reproducibility has been
>> addressed [1], we can revert this patch. This will resolve issues with
>> cgo applications becoming unreprodcible.
>>
>> Currently go considers link arguments to be sacred, meaning any change
>> should produce a different binary output. They ensure this by baking
>> link arguments into the intermediary output, changing the content ID of
>> that step. As such, the marco prefixes inadvertently end up adding build
>> paths to the output binary instead of removing them if they are passed
>> as link arguments to cgo applications.
>>
>> These paths are later stripped out again, but at this point the content
>> ID of the dependency has changed and thus the build ID of the end
>> application will be affected by the cascade of hash changes. See the
>> upstream bug for more information [2].
>>
>> This reverts commit fddaecc88979967d0e00e2fafdbaaabec030da9f.
>>
>> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101473
>> [2] https://github.com/golang/go/issues/77218
>>
>> Signed-off-by: Randolph Sapp <rs@ti.com>
>> ---
>>
>> This resolves the previously reported emptty issues:
>> https://lists.openembedded.org/g/openembedded-core/message/228549
>>
>>  meta/conf/bitbake.conf | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
>> index 88f4d0df69..da873c3f4e 100644
>> --- a/meta/conf/bitbake.conf
>> +++ b/meta/conf/bitbake.conf
>> @@ -634,7 +634,7 @@ TARGET_LINK_HASH_STYLE ?= "${@['-Wl,--hash-style=gnu',''][d.getVar('LINKER_HASH_ ASNEEDED ?= "-Wl,--as-needed"
>>
>>  export LDFLAGS = "${TARGET_LDFLAGS}"
>> -TARGET_LDFLAGS = "-Wl,-O1 ${TARGET_LINK_HASH_STYLE} ${ASNEEDED} ${DEBUG_PREFIX_MAP}"
>> +TARGET_LDFLAGS = "-Wl,-O1 ${TARGET_LINK_HASH_STYLE} ${ASNEEDED}"
>
> Hi,
>
> After check the related gcc bug and yocto bug,  gcc bug comments 21
> ([1])  and yocto bug comments 13 ([2]),
>
> my understanding is that,  when lto is enabled,  even with gcc fix
> [3],  we still need DEBUG_PREFIX_MAP in LDFLAGS
>
> to make bin reproducible. Also seems Tony's commit [4] is after gcc
> fix [3].
>
> [1]  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101473#c21
>
> [2]  https://bugzilla.yoctoproject.org/show_bug.cgi?id=14481#c13
>
> [3]  https://gcc.gnu.org/g:7cc2df084b7977653a9b59cbc34a9ad500ae619c
>
> [4] 
> https://git.openembedded.org/openembedded-core/commit/?id=fddaecc88979967d0e00e2fafdbaaabec030da9f
>
>
> @Tony, @Randolph, Could please correct me if my understanding is not
> right, Thanks.
>
>
Yes, LDFLAGS needs DEBUG_PREFIX_MAP to make LTO builds reproducible,
unless something else has changed since 2021 to make it unnecessary. I
have not kept up with the issue.

Tony

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

[Randolph Sapp]

On Mon Jan 26, 2026 at 9:04 AM CST, Tony Battersby wrote:
> On 1/26/26 03:39, Changqing Li wrote:
>>
>>
>> On 1/23/26 03:50, Randolph Sapp via lists.openembedded.org 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.
>>>
>>> From: Randolph Sapp <rs@ti.com>
>>>
>>> Now that the previous bug affecting binary reproducibility has been
>>> addressed [1], we can revert this patch. This will resolve issues with
>>> cgo applications becoming unreprodcible.
>>>
>>> Currently go considers link arguments to be sacred, meaning any change
>>> should produce a different binary output. They ensure this by baking
>>> link arguments into the intermediary output, changing the content ID of
>>> that step. As such, the marco prefixes inadvertently end up adding build
>>> paths to the output binary instead of removing them if they are passed
>>> as link arguments to cgo applications.
>>>
>>> These paths are later stripped out again, but at this point the content
>>> ID of the dependency has changed and thus the build ID of the end
>>> application will be affected by the cascade of hash changes. See the
>>> upstream bug for more information [2].
>>>
>>> This reverts commit fddaecc88979967d0e00e2fafdbaaabec030da9f.
>>>
>>> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101473
>>> [2] https://github.com/golang/go/issues/77218
>>>
>>> Signed-off-by: Randolph Sapp <rs@ti.com>
>>> ---
>>>
>>> This resolves the previously reported emptty issues:
>>> https://lists.openembedded.org/g/openembedded-core/message/228549
>>>
>>>  meta/conf/bitbake.conf | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
>>> index 88f4d0df69..da873c3f4e 100644
>>> --- a/meta/conf/bitbake.conf
>>> +++ b/meta/conf/bitbake.conf
>>> @@ -634,7 +634,7 @@ TARGET_LINK_HASH_STYLE ?= "${@['-Wl,--hash-style=gnu',''][d.getVar('LINKER_HASH_ ASNEEDED ?= "-Wl,--as-needed"
>>>
>>>  export LDFLAGS = "${TARGET_LDFLAGS}"
>>> -TARGET_LDFLAGS = "-Wl,-O1 ${TARGET_LINK_HASH_STYLE} ${ASNEEDED} ${DEBUG_PREFIX_MAP}"
>>> +TARGET_LDFLAGS = "-Wl,-O1 ${TARGET_LINK_HASH_STYLE} ${ASNEEDED}"
>>
>> Hi,
>>
>> After check the related gcc bug and yocto bug,  gcc bug comments 21
>> ([1])  and yocto bug comments 13 ([2]),
>>
>> my understanding is that,  when lto is enabled,  even with gcc fix
>> [3],  we still need DEBUG_PREFIX_MAP in LDFLAGS
>>
>> to make bin reproducible. Also seems Tony's commit [4] is after gcc
>> fix [3].
>>
>> [1]  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101473#c21
>>
>> [2]  https://bugzilla.yoctoproject.org/show_bug.cgi?id=14481#c13
>>
>> [3]  https://gcc.gnu.org/g:7cc2df084b7977653a9b59cbc34a9ad500ae619c
>>
>> [4] 
>> https://git.openembedded.org/openembedded-core/commit/?id=fddaecc88979967d0e00e2fafdbaaabec030da9f
>>
>>
>> @Tony, @Randolph, Could please correct me if my understanding is not
>> right, Thanks.
>>
>>
> Yes, LDFLAGS needs DEBUG_PREFIX_MAP to make LTO builds reproducible,
> unless something else has changed since 2021 to make it unnecessary. I
> have not kept up with the issue.
>
> Tony

I think there has been some change because I tested this locally with the normal
reproducible builds selftest and no new packages were added to the failing list.
This included oe-core and some layers from meta-openembedded as well.

The example code given in the report is fairly rudimentary, we should have hit
the bug if it was still in effect across a majority of packages if my
understanding is correct.

I'm also curious to see what golang want's to do about this though. Baking build
options into a binary seems a little silly, but I'm sure there was some unusual
behavior that led them to that point.

As indicated on another thread, we could also just remove this string from Go
packages LDFLAGS if that puts everyone at ease.

- Randolph

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

[Changqing Li]

[-- Attachment #1: Type: text/plain, Size: 4985 bytes --]


On 1/27/26 04:50, Randolph Sapp via lists.openembedded.org 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 Mon Jan 26, 2026 at 9:04 AM CST, Tony Battersby wrote:
>> On 1/26/26 03:39, Changqing Li wrote:
>>>
>>> On 1/23/26 03:50, Randolph Sapp via lists.openembedded.org 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.
>>>>
>>>> From: Randolph Sapp<rs@ti.com>
>>>>
>>>> Now that the previous bug affecting binary reproducibility has been
>>>> addressed [1], we can revert this patch. This will resolve issues with
>>>> cgo applications becoming unreprodcible.
>>>>
>>>> Currently go considers link arguments to be sacred, meaning any change
>>>> should produce a different binary output. They ensure this by baking
>>>> link arguments into the intermediary output, changing the content ID of
>>>> that step. As such, the marco prefixes inadvertently end up adding build
>>>> paths to the output binary instead of removing them if they are passed
>>>> as link arguments to cgo applications.
>>>>
>>>> These paths are later stripped out again, but at this point the content
>>>> ID of the dependency has changed and thus the build ID of the end
>>>> application will be affected by the cascade of hash changes. See the
>>>> upstream bug for more information [2].
>>>>
>>>> This reverts commit fddaecc88979967d0e00e2fafdbaaabec030da9f.
>>>>
>>>> [1]https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101473
>>>> [2]https://github.com/golang/go/issues/77218
>>>>
>>>> Signed-off-by: Randolph Sapp<rs@ti.com>
>>>> ---
>>>>
>>>> This resolves the previously reported emptty issues:
>>>> https://lists.openembedded.org/g/openembedded-core/message/228549
>>>>
>>>>   meta/conf/bitbake.conf | 2 +-
>>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
>>>> index 88f4d0df69..da873c3f4e 100644
>>>> --- a/meta/conf/bitbake.conf
>>>> +++ b/meta/conf/bitbake.conf
>>>> @@ -634,7 +634,7 @@ TARGET_LINK_HASH_STYLE ?="${@['-Wl,--hash-style=gnu',''][d.getVar('LINKER_HASH_ ASNEEDED ?= "-Wl,--as-needed"
>>>>
>>>>   export LDFLAGS = "${TARGET_LDFLAGS}"
>>>> -TARGET_LDFLAGS = "-Wl,-O1 ${TARGET_LINK_HASH_STYLE} ${ASNEEDED} ${DEBUG_PREFIX_MAP}"
>>>> +TARGET_LDFLAGS = "-Wl,-O1 ${TARGET_LINK_HASH_STYLE} ${ASNEEDED}"
>>> Hi,
>>>
>>> After check the related gcc bug and yocto bug,  gcc bug comments 21
>>> ([1])  and yocto bug comments 13 ([2]),
>>>
>>> my understanding is that,  when lto is enabled,  even with gcc fix
>>> [3],  we still need DEBUG_PREFIX_MAP in LDFLAGS
>>>
>>> to make bin reproducible. Also seems Tony's commit [4] is after gcc
>>> fix [3].
>>>
>>> [1]https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101473#c21
>>>
>>> [2]https://bugzilla.yoctoproject.org/show_bug.cgi?id=14481#c13
>>>
>>> [3]https://gcc.gnu.org/g:7cc2df084b7977653a9b59cbc34a9ad500ae619c
>>>
>>> [4]
>>> https://git.openembedded.org/openembedded-core/commit/?id=fddaecc88979967d0e00e2fafdbaaabec030da9f
>>>
>>>
>>> @Tony, @Randolph, Could please correct me if my understanding is not
>>> right, Thanks.
>>>
>>>
>> Yes, LDFLAGS needs DEBUG_PREFIX_MAP to make LTO builds reproducible,
>> unless something else has changed since 2021 to make it unnecessary. I
>> have not kept up with the issue.
>>
>> Tony
> I think there has been some change because I tested this locally with the normal
> reproducible builds selftest and no new packages were added to the failing list.
> This included oe-core and some layers from meta-openembedded as well.

Got it,  if DEBUG_PREFIX_MAP is not needed any more,  I think remove 
DEBUG_PREFIX_MAP from LDFLAGS

is a good way to fix the issue.

>
> The example code given in the report is fairly rudimentary, we should have hit
> the bug if it was still in effect across a majority of packages if my
> understanding is correct.
>
> I'm also curious to see what golang want's to do about this though. Baking build
> options into a binary seems a little silly, but I'm sure there was some unusual
> behavior that led them to that point.

+1

//Changqing

>
> As indicated on another thread, we could also just remove this string from Go
> packages LDFLAGS if that puts everyone at ease.
>
> - Randolph
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#230026):https://lists.openembedded.org/g/openembedded-core/message/230026
> Mute This Topic:https://lists.openembedded.org/mt/117408334/3616873
> Group Owner:openembedded-core+owner@lists.openembedded.org
> Unsubscribe:https://lists.openembedded.org/g/openembedded-core/unsub [changqing.li@windriver.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

[-- Attachment #2: Type: text/html, Size: 7679 bytes --]

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

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 5227 bytes --]

I am seeing some additional diagnostics see

https://autobuilder.yoctoproject.org/valkyrie/api/v2/logs/5119153/raw_inline

I wonder if this is related.


On Mon, Jan 26, 2026 at 6:50 PM Changqing Li via lists.openembedded.org <
changqing.li=windriver.com@lists.openembedded.org> wrote:

>
> On 1/27/26 04:50, Randolph Sapp via lists.openembedded.org 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 Mon Jan 26, 2026 at 9:04 AM CST, Tony Battersby wrote:
>
> On 1/26/26 03:39, Changqing Li wrote:
>
> On 1/23/26 03:50, Randolph Sapp via lists.openembedded.org 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.
>
> From: Randolph Sapp <rs@ti.com> <rs@ti.com>
>
> Now that the previous bug affecting binary reproducibility has been
> addressed [1], we can revert this patch. This will resolve issues with
> cgo applications becoming unreprodcible.
>
> Currently go considers link arguments to be sacred, meaning any change
> should produce a different binary output. They ensure this by baking
> link arguments into the intermediary output, changing the content ID of
> that step. As such, the marco prefixes inadvertently end up adding build
> paths to the output binary instead of removing them if they are passed
> as link arguments to cgo applications.
>
> These paths are later stripped out again, but at this point the content
> ID of the dependency has changed and thus the build ID of the end
> application will be affected by the cascade of hash changes. See the
> upstream bug for more information [2].
>
> This reverts commit fddaecc88979967d0e00e2fafdbaaabec030da9f.
>
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101473
> [2] https://github.com/golang/go/issues/77218
>
> Signed-off-by: Randolph Sapp <rs@ti.com> <rs@ti.com>
> ---
>
> This resolves the previously reported emptty issues:https://lists.openembedded.org/g/openembedded-core/message/228549
>
>  meta/conf/bitbake.conf | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index 88f4d0df69..da873c3f4e 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -634,7 +634,7 @@ TARGET_LINK_HASH_STYLE ?= "${@['-Wl,--hash-style=gnu',''][d.getVar('LINKER_HASH_ ASNEEDED ?= " <$%7B@['-Wl,--hash-style=gnu',''][d.getVar('LINKER_HASH_ASNEEDED?=>-Wl,--as-needed"
>
>  export LDFLAGS = "${TARGET_LDFLAGS}"
> -TARGET_LDFLAGS = "-Wl,-O1 ${TARGET_LINK_HASH_STYLE} ${ASNEEDED} ${DEBUG_PREFIX_MAP}"
> +TARGET_LDFLAGS = "-Wl,-O1 ${TARGET_LINK_HASH_STYLE} ${ASNEEDED}"
>
> Hi,
>
> After check the related gcc bug and yocto bug,  gcc bug comments 21
> ([1])  and yocto bug comments 13 ([2]),
>
> my understanding is that,  when lto is enabled,  even with gcc fix
> [3],  we still need DEBUG_PREFIX_MAP in LDFLAGS
>
> to make bin reproducible. Also seems Tony's commit [4] is after gcc
> fix [3].
>
> [1]  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101473#c21
>
> [2]  https://bugzilla.yoctoproject.org/show_bug.cgi?id=14481#c13
>
> [3]  https://gcc.gnu.org/g:7cc2df084b7977653a9b59cbc34a9ad500ae619c
>
> [4] https://git.openembedded.org/openembedded-core/commit/?id=fddaecc88979967d0e00e2fafdbaaabec030da9f
>
>
> @Tony, @Randolph, Could please correct me if my understanding is not
> right, Thanks.
>
>
>
> Yes, LDFLAGS needs DEBUG_PREFIX_MAP to make LTO builds reproducible,
> unless something else has changed since 2021 to make it unnecessary. I
> have not kept up with the issue.
>
> Tony
>
> I think there has been some change because I tested this locally with the normal
> reproducible builds selftest and no new packages were added to the failing list.
> This included oe-core and some layers from meta-openembedded as well.
>
> Got it,  if DEBUG_PREFIX_MAP is not needed any more,  I think remove DEBUG_PREFIX_MAP
> from LDFLAGS
>
> is a good way to fix the issue.
>
> The example code given in the report is fairly rudimentary, we should have hit
> the bug if it was still in effect across a majority of packages if my
> understanding is correct.
>
> I'm also curious to see what golang want's to do about this though. Baking build
> options into a binary seems a little silly, but I'm sure there was some unusual
> behavior that led them to that point.
>
> +1
>
> //Changqing
>
> As indicated on another thread, we could also just remove this string from Go
> packages LDFLAGS if that puts everyone at ease.
>
> - Randolph
>
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#230027):
> https://lists.openembedded.org/g/openembedded-core/message/230027
> Mute This Topic: https://lists.openembedded.org/mt/117408334/1997914
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [
> raj.khem@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

[-- Attachment #2: Type: text/html, Size: 7983 bytes --]

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

[Randolph Sapp]

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.

If that bug is actually still in effect then this requires some change to golang
to avoid baking cgo_ldflags into the binaries. Right now we can get away with a
go class specific LDFLAGS override if we want to, but that GCC bug may begin to
affect go binary reproducibility in the future.

- Randolph

> On Mon, Jan 26, 2026 at 6:50 PM Changqing Li via lists.openembedded.org <
> changqing.li=windriver.com@lists.openembedded.org> wrote:
>
>>
>> On 1/27/26 04:50, Randolph Sapp via lists.openembedded.org 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 Mon Jan 26, 2026 at 9:04 AM CST, Tony Battersby wrote:
>>
>> On 1/26/26 03:39, Changqing Li wrote:
>>
>> On 1/23/26 03:50, Randolph Sapp via lists.openembedded.org 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.
>>
>> From: Randolph Sapp <rs@ti.com> <rs@ti.com>
>>
>> Now that the previous bug affecting binary reproducibility has been
>> addressed [1], we can revert this patch. This will resolve issues with
>> cgo applications becoming unreprodcible.
>>
>> Currently go considers link arguments to be sacred, meaning any change
>> should produce a different binary output. They ensure this by baking
>> link arguments into the intermediary output, changing the content ID of
>> that step. As such, the marco prefixes inadvertently end up adding build
>> paths to the output binary instead of removing them if they are passed
>> as link arguments to cgo applications.
>>
>> These paths are later stripped out again, but at this point the content
>> ID of the dependency has changed and thus the build ID of the end
>> application will be affected by the cascade of hash changes. See the
>> upstream bug for more information [2].
>>
>> This reverts commit fddaecc88979967d0e00e2fafdbaaabec030da9f.
>>
>> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101473
>> [2] https://github.com/golang/go/issues/77218
>>
>> Signed-off-by: Randolph Sapp <rs@ti.com> <rs@ti.com>
>> ---
>>
>> This resolves the previously reported emptty issues:https://lists.openembedded.org/g/openembedded-core/message/228549
>>
>>  meta/conf/bitbake.conf | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
>> index 88f4d0df69..da873c3f4e 100644
>> --- a/meta/conf/bitbake.conf
>> +++ b/meta/conf/bitbake.conf
>> @@ -634,7 +634,7 @@ TARGET_LINK_HASH_STYLE ?= "${@['-Wl,--hash-style=gnu',''][d.getVar('LINKER_HASH_ ASNEEDED ?= " <$%7B@['-Wl,--hash-style=gnu',''][d.getVar('LINKER_HASH_ASNEEDED?=>-Wl,--as-needed"
>>
>>  export LDFLAGS = "${TARGET_LDFLAGS}"
>> -TARGET_LDFLAGS = "-Wl,-O1 ${TARGET_LINK_HASH_STYLE} ${ASNEEDED} ${DEBUG_PREFIX_MAP}"
>> +TARGET_LDFLAGS = "-Wl,-O1 ${TARGET_LINK_HASH_STYLE} ${ASNEEDED}"
>>
>> Hi,
>>
>> After check the related gcc bug and yocto bug,  gcc bug comments 21
>> ([1])  and yocto bug comments 13 ([2]),
>>
>> my understanding is that,  when lto is enabled,  even with gcc fix
>> [3],  we still need DEBUG_PREFIX_MAP in LDFLAGS
>>
>> to make bin reproducible. Also seems Tony's commit [4] is after gcc
>> fix [3].
>>
>> [1]  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101473#c21
>>
>> [2]  https://bugzilla.yoctoproject.org/show_bug.cgi?id=14481#c13
>>
>> [3]  https://gcc.gnu.org/g:7cc2df084b7977653a9b59cbc34a9ad500ae619c
>>
>> [4] https://git.openembedded.org/openembedded-core/commit/?id=fddaecc88979967d0e00e2fafdbaaabec030da9f
>>
>>
>> @Tony, @Randolph, Could please correct me if my understanding is not
>> right, Thanks.
>>
>>
>>
>> Yes, LDFLAGS needs DEBUG_PREFIX_MAP to make LTO builds reproducible,
>> unless something else has changed since 2021 to make it unnecessary. I
>> have not kept up with the issue.
>>
>> Tony
>>
>> I think there has been some change because I tested this locally with the normal
>> reproducible builds selftest and no new packages were added to the failing list.
>> This included oe-core and some layers from meta-openembedded as well.
>>
>> Got it,  if DEBUG_PREFIX_MAP is not needed any more,  I think remove DEBUG_PREFIX_MAP
>> from LDFLAGS
>>
>> is a good way to fix the issue.
>>
>> The example code given in the report is fairly rudimentary, we should have hit
>> the bug if it was still in effect across a majority of packages if my
>> understanding is correct.
>>
>> I'm also curious to see what golang want's to do about this though. Baking build
>> options into a binary seems a little silly, but I'm sure there was some unusual
>> behavior that led them to that point.
>>
>> +1
>>
>> //Changqing
>>
>> As indicated on another thread, we could also just remove this string from Go
>> packages LDFLAGS if that puts everyone at ease.
>>
>> - Randolph
>>
>>
>>
>> 
>>
>>

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

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 6328 bytes --]

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.


>
> If that bug is actually still in effect then this requires some change to
> golang
> to avoid baking cgo_ldflags into the binaries. Right now we can get away
> with a
> go class specific LDFLAGS override if we want to, but that GCC bug may
> begin to
> affect go binary reproducibility in the future.
>
> - Randolph
>
> > On Mon, Jan 26, 2026 at 6:50 PM Changqing Li via lists.openembedded.org
> <
> > changqing.li=windriver.com@lists.openembedded.org> wrote:
> >
> >>
> >> On 1/27/26 04:50, Randolph Sapp via lists.openembedded.org 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 Mon Jan 26, 2026 at 9:04 AM CST, Tony Battersby wrote:
> >>
> >> On 1/26/26 03:39, Changqing Li wrote:
> >>
> >> On 1/23/26 03:50, Randolph Sapp via lists.openembedded.org 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.
> >>
> >> From: Randolph Sapp <rs@ti.com> <rs@ti.com>
> >>
> >> Now that the previous bug affecting binary reproducibility has been
> >> addressed [1], we can revert this patch. This will resolve issues with
> >> cgo applications becoming unreprodcible.
> >>
> >> Currently go considers link arguments to be sacred, meaning any change
> >> should produce a different binary output. They ensure this by baking
> >> link arguments into the intermediary output, changing the content ID of
> >> that step. As such, the marco prefixes inadvertently end up adding build
> >> paths to the output binary instead of removing them if they are passed
> >> as link arguments to cgo applications.
> >>
> >> These paths are later stripped out again, but at this point the content
> >> ID of the dependency has changed and thus the build ID of the end
> >> application will be affected by the cascade of hash changes. See the
> >> upstream bug for more information [2].
> >>
> >> This reverts commit fddaecc88979967d0e00e2fafdbaaabec030da9f.
> >>
> >> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101473
> >> [2] https://github.com/golang/go/issues/77218
> >>
> >> Signed-off-by: Randolph Sapp <rs@ti.com> <rs@ti.com>
> >> ---
> >>
> >> This resolves the previously reported emptty issues:
> https://lists.openembedded.org/g/openembedded-core/message/228549
> >>
> >>  meta/conf/bitbake.conf | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> >> index 88f4d0df69..da873c3f4e 100644
> >> --- a/meta/conf/bitbake.conf
> >> +++ b/meta/conf/bitbake.conf
> >> @@ -634,7 +634,7 @@ TARGET_LINK_HASH_STYLE ?=
> "${@['-Wl,--hash-style=gnu',''][d.getVar('LINKER_HASH_ ASNEEDED ?= " <$%7B@
> ['-Wl,--hash-style=gnu',''][d.getVar('LINKER_HASH_ASNEEDED?=>-Wl,--as-needed"
> >>
> >>  export LDFLAGS = "${TARGET_LDFLAGS}"
> >> -TARGET_LDFLAGS = "-Wl,-O1 ${TARGET_LINK_HASH_STYLE} ${ASNEEDED}
> ${DEBUG_PREFIX_MAP}"
> >> +TARGET_LDFLAGS = "-Wl,-O1 ${TARGET_LINK_HASH_STYLE} ${ASNEEDED}"
> >>
> >> Hi,
> >>
> >> After check the related gcc bug and yocto bug,  gcc bug comments 21
> >> ([1])  and yocto bug comments 13 ([2]),
> >>
> >> my understanding is that,  when lto is enabled,  even with gcc fix
> >> [3],  we still need DEBUG_PREFIX_MAP in LDFLAGS
> >>
> >> to make bin reproducible. Also seems Tony's commit [4] is after gcc
> >> fix [3].
> >>
> >> [1]  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101473#c21
> >>
> >> [2]  https://bugzilla.yoctoproject.org/show_bug.cgi?id=14481#c13
> >>
> >> [3]  https://gcc.gnu.org/g:7cc2df084b7977653a9b59cbc34a9ad500ae619c
> >>
> >> [4]
> https://git.openembedded.org/openembedded-core/commit/?id=fddaecc88979967d0e00e2fafdbaaabec030da9f
> >>
> >>
> >> @Tony, @Randolph, Could please correct me if my understanding is not
> >> right, Thanks.
> >>
> >>
> >>
> >> Yes, LDFLAGS needs DEBUG_PREFIX_MAP to make LTO builds reproducible,
> >> unless something else has changed since 2021 to make it unnecessary. I
> >> have not kept up with the issue.
> >>
> >> Tony
> >>
> >> I think there has been some change because I tested this locally with
> the normal
> >> reproducible builds selftest and no new packages were added to the
> failing list.
> >> This included oe-core and some layers from meta-openembedded as well.
> >>
> >> Got it,  if DEBUG_PREFIX_MAP is not needed any more,  I think remove
> DEBUG_PREFIX_MAP
> >> from LDFLAGS
> >>
> >> is a good way to fix the issue.
> >>
> >> The example code given in the report is fairly rudimentary, we should
> have hit
> >> the bug if it was still in effect across a majority of packages if my
> >> understanding is correct.
> >>
> >> I'm also curious to see what golang want's to do about this though.
> Baking build
> >> options into a binary seems a little silly, but I'm sure there was some
> unusual
> >> behavior that led them to that point.
> >>
> >> +1
> >>
> >> //Changqing
> >>
> >> As indicated on another thread, we could also just remove this string
> from Go
> >> packages LDFLAGS if that puts everyone at ease.
> >>
> >> - Randolph
> >>
> >>
> >>
> >>
> >>
> >>
>
>

[-- Attachment #2: Type: text/html, Size: 9491 bytes --]

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

[Ricardo de Araujo (Salveti)]

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.

Thanks,

Ricardo

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

[Randolph Sapp]

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

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.

- Randolph

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

[Ricardo de Araujo (Salveti)]

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

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

[Randolph Sapp]

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

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

[Ricardo de Araujo (Salveti)]

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.

Thanks,

Ricardo

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

[Changqing Li]

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

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

[Randolph Sapp]

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