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

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

[-- 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 --]