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 < [email protected]> 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 <[email protected]> <[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]> <[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 ?= " > <$%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 (#230030): https://lists.openembedded.org/g/openembedded-core/message/230030 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]] -=-=-=-=-=-=-=-=-=-=-=-
