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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#230010): 
https://lists.openembedded.org/g/openembedded-core/message/230010
Mute This Topic: https://lists.openembedded.org/mt/117408334/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to