On Tue, Jan 27, 2026 at 8:31 AM Randolph Sapp <[email protected]> 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 > < > > [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 (#230058): https://lists.openembedded.org/g/openembedded-core/message/230058 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]] -=-=-=-=-=-=-=-=-=-=-=-
