When investigating #2357798, I noticed that /usr/sbin/ldconfig does not have package notes. It'd be easier to figure out what is going on if we were able to query the binary for its provenience: $ readelf --string-dump=.note.package /bin/ldconfig readelf: Warning: Section '.note.package' was not dumped because it does not exist (The current alternative is to use the buildid or hash of the file, download some packages for koji, extract the same data, and look for a match. 'readelf' or 'systemd-analyze inspect-elf' are … nicer.) Reproducible: Always
You can feed the build ID to the debuginfod service: debuginfod-find -v debuginfo 1afd01f4bd3e689a67206c10c20e69921ba9be93 It shows the package version in the debug output if it is not yet cached. This is not ideal, so I requested an enhancement here: debuginfod-find: Way to obtain package metadata <https://inbox.sourceware.org/elfutils-devel/87o6wkimkj.fsf@oldenburg.str.redhat.com/> Regarding glibc package notes, the opposite bug was filed against Ubuntu today: glibc package metadata in all binaries <https://bugs.launchpad.net/bugs/2109333> I assume this is due to the *crt*.o files and libc_nonshared.a. So extra some scripting will be required, and it's not just a simple build flags change for the glibc build.
Adding additional sections to glibc will require validation. We're fairly careful with what we add because of the impact it has on other tooling.
> debuginfod-find -v debuginfo 1afd01f4bd3e689a67206c10c20e69921ba9be93 Thanks, that is useful. > https://bugs.launchpad.net/bugs/2109333 Yeah, it seems that the note gets copied from Scrt1.o to the linked binary. I didn't know that the note would be copied like that, but it is reasonable in hindsight. Nevertheless, the solution seems simple: do not add the note there. -- Another reason why we want this: coredumps. For example, for bash, I get: $ bash -c 'kill -SEGV $$' $ coredumpctl info | grep Module Module /usr/bin/bash from rpm bash-5.2.37-1.fc42.x86_64 Module libtinfo.so.6 from rpm ncurses-6.5-5.20250125.fc42.x86_64 $ ldd /usr/bin/bash linux-vdso.so.1 (0x00007fe5ea48f000) libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007fe5ea2cd000) libc.so.6 => /lib64/libc.so.6 (0x00007fe5ea0db000) /lib64/ld-linux-x86-64.so.2 (0x00007fe5ea491000) The info for the linker and libc is missing. That'd be nice to have this. (Also the info for the vdso. I guess we could ask for it to be added too.)
This requires investigation. As the referenced Launchpad bug shows, we can only do this for the shared objects, not the .o/.a files. I didn't find an immediate way to inject the required flags. This does not seem to work: env LDFLAGS-c.so=… make … The environment variable does not have the desired effect.
FEDORA-2026-2260c211ab (package-notes-0.5-16.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-2260c211ab
FEDORA-2026-2260c211ab (package-notes-0.5-16.fc45) has been pushed to the Fedora 45 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-6557cad57e (package-notes-0.5-16.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-6557cad57e
FEDORA-2026-6557cad57e (package-notes-0.5-16.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-5d354b29b3 (glibc-2.43-2.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-5d354b29b3
FEDORA-2026-a28338788d (glibc-2.43.9000-1.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-a28338788d
FEDORA-2026-a28338788d (glibc-2.43.9000-1.fc45) has been pushed to the Fedora 45 stable repository. If problem still persists, please make note of it in this bug report.
Thank you!