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. TonyI 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] -=-=-=-=-=-=-=-=-=-=-=-