Building zpaqfranz-64.5-1 on Fedora 44 <https://bodhi.fedoraproject.org/updates/FEDORA-2026-a32d4615b5> and on Fedora 45 <https://bodhi.fedoraproject.org/updates/FEDORA-2026-caf0f1ac36> manifests a regression in annocheck sanity test <https://artifacts.dev.testing-farm.io/2c8d7832-97dd-4cd8-83bd-4380916344a7/>, causing a Fedora CI failure with this output: Command: annocheck --no-use-debuginfod --ignore-unknown --verbose --profile=fedora --debug-dir=/usr/lib/debug/ ./usr/bin/zpaqfranz Exit Code: 1 annocheck: Version 12.99. Hardened: ./usr/bin/zpaqfranz: PASS: pie test because the ELF file header has the correct type Hardened: ./usr/bin/zpaqfranz: info: written in C++ (source: DW_AT_language string). Hardened: ./usr/bin/zpaqfranz: info: seen tool Gimple version 16. Hardened: ./usr/bin/zpaqfranz: PASS: pic test because option found in DW_AT_producer string Hardened: ./usr/bin/zpaqfranz: PASS: stack-prot test because option found in DW_AT_producer string Hardened: ./usr/bin/zpaqfranz: PASS: stack-clash test because option found in DW_AT_producer string Hardened: ./usr/bin/zpaqfranz: PASS: optimization test because option found in DW_AT_producer string Hardened: ./usr/bin/zpaqfranz: PASS: branch-protection test because correct option found in DW_AT_producer string Hardened: ./usr/bin/zpaqfranz: info: seen tool GCC version 16. Hardened: ./usr/bin/zpaqfranz: PASS: lto test because detected in DW_AT_producer string Hardened: ./usr/bin/zpaqfranz: PASS: fortify test because found in DW_AT_producer string Hardened: ./usr/bin/zpaqfranz: PASS: writable-got test Hardened: ./usr/bin/zpaqfranz: PASS: dynamic-segment test Hardened: ./usr/bin/zpaqfranz: PASS: bind-now test because BIND_NOW dynamic flag seen Hardened: ./usr/bin/zpaqfranz: FAIL: dynamic-tags test because the BTI_PLT flag is missing from the dynamic tags Hardened: ./usr/bin/zpaqfranz: info: For more information visit: https://sourceware.org/annobin/annobin.html/Test-dynamic-tags.html Hardened: ./usr/bin/zpaqfranz: PASS: gnu-stack test because stack segment exists with the correct permissions Hardened: ./usr/bin/zpaqfranz: PASS: gnu-relro test Hardened: ./usr/bin/zpaqfranz: PASS: notes test because annobin notes found in the .annobin.notes section Hardened: ./usr/bin/zpaqfranz: skip: fast test because function abi-note.c is part of the C library's static code and does use math functions Hardened: ./usr/bin/zpaqfranz: skip: lto test because function abi-note.c is part of the C library which is deliberately built without LTO Hardened: ./usr/bin/zpaqfranz: PASS: implicit-values test because -Wimplicit-int and -Wimplicit-function-decalration enabled Hardened: ./usr/bin/zpaqfranz: skip: fortify test because function abi-note.c is part of the C library, and as such it does not need fortification Hardened: ./usr/bin/zpaqfranz: PASS: glibcxx-assertions test Hardened: ./usr/bin/zpaqfranz: skip: warnings test because LTO compilation discards preprocessor options Hardened: ./usr/bin/zpaqfranz: skip: implicit-values test because -Wimplicit-int setting is hidden by LTO Hardened: ./usr/bin/zpaqfranz: info: seen tool Gas version 1. Hardened: ./usr/bin/zpaqfranz: skip: gaps test because string notes imply full coverage Hardened: ./usr/bin/zpaqfranz: skip: cf-protection test because not an x86_64 binary Hardened: ./usr/bin/zpaqfranz: PASS: entry test because no negative result detected Hardened: ./usr/bin/zpaqfranz: skip: go-revision test because no GO compiled code found Hardened: ./usr/bin/zpaqfranz: PASS: instrumentation test because no negative result detected Hardened: ./usr/bin/zpaqfranz: PASS: load-segments test because no negative result detected Hardened: ./usr/bin/zpaqfranz: PASS: production test because no negative result detected Hardened: ./usr/bin/zpaqfranz: FAIL: property-note test because no .note.gnu.property section found Hardened: ./usr/bin/zpaqfranz: info: For more information visit: https://sourceware.org/annobin/annobin.html/Test-property-note.html Hardened: ./usr/bin/zpaqfranz: PASS: run-path test because no negative result detected Hardened: ./usr/bin/zpaqfranz: PASS: short-enums test because no negative result detected Hardened: ./usr/bin/zpaqfranz: skip: stack-realign test because not an i686 executable Hardened: ./usr/bin/zpaqfranz: PASS: textrel test because no negative result detected Hardened: ./usr/bin/zpaqfranz: PASS: threads test because no negative result detected Hardened: ./usr/bin/zpaqfranz: PASS: unicode test because no negative result detected Hardened: ./usr/bin/zpaqfranz: Overall: FAIL. I only observed this failure in AArch64 in Fedora 45. I minimized the reproducer to: # cat test.c int main(void) { return 0; } Compiling with "-flto=auto -g -mbranch-protection=standard" works with gcc-16.0.1-0.5.fc44.aarch64 and the .note.gnu.property is present: # gcc -flto=auto -g -mbranch-protection=standard test.c -o a.out && readelf -j .note.gnu.property ./a.out Displaying notes found in: .note.gnu.property Owner Data size Description GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0 Properties: AArch64 feature: BTI, PAC, GCS Upgrading gcc to gcc-16.0.1-0.7.fc45.aarch64 triggers the regression, the .note.gnu.property disappears: # gcc -flto=auto -g -mbranch-protection=standard test.c -o a.out && readelf -j .note.gnu.property ./a.out readelf: Warning: Section '.note.gnu.property' was not dumped because it does not exist Removing "-flto=auto" or "-g" options returns the .note.gnu.property. Comparing disassembled code (compiled with -O0) reveals that functions in .plt section are missing BTI instructions.
> Building zpaqfranz-64.5-1 on Fedora 44 <https://bodhi.fedoraproject.org/updates/FEDORA-2026-a32d4615b5> and on Fedora 45 <https://bodhi.fedoraproject.org/updates/FEDORA-2026-caf0f1ac36> manifests a regression in annocheck sanity test <https://artifacts.dev.testing-farm.io/2c8d7832-97dd-4cd8-83bd-4380916344a7/>, causing a Fedora CI failure with this output I meant that on Fedora 44 there is no problem. The problem is on Fedora 45.
This also affects dovecot-fts-xapian.
Note that the .o files are putting the pac/bti/gcs information in the eabi defined section use 'readelf -x | grep -i tag' to find them. The final linked exe should have them in the gnu notes sections as expected. Try `gcc main.o` just to finalize the link against the standard library and then dump the notes section.
Try to use the latest built binutils as well which should understand this behavior.
With old binutils-2.46-1.fc45.aarch64 the tags are present in the object file, but lost when linking: # gcc -flto=auto -g -mbranch-protection=standard test.c -c # readelf -a test.o | grep Tag Tag_Feature_BTI: 1 (0x1) Tag_Feature_PAC: 1 (0x1) Tag_Feature_GCS: 1 (0x1) # gcc test.o # readelf -j .note.gnu.property a.out readelf: Warning: Section '.note.gnu.property' was not dumped because it does not exist After upgrading binutils to 2.46.50-1.fc45.aarch64 there is not change. Relinking the objects, or even recompiling them does not help.
(In reply to Petr Pisar from comment #5) > With old binutils-2.46-1.fc45.aarch64 the tags are present in the object > file, but lost when linking: > > # gcc -flto=auto -g -mbranch-protection=standard test.c -c > # readelf -a test.o | grep Tag > Tag_Feature_BTI: 1 (0x1) > Tag_Feature_PAC: 1 (0x1) > Tag_Feature_GCS: 1 (0x1) > # gcc test.o > # readelf -j .note.gnu.property a.out > readelf: Warning: Section '.note.gnu.property' was not dumped because it > does not exist > > > After upgrading binutils to 2.46.50-1.fc45.aarch64 there is not change. > Relinking the objects, or even recompiling them does not help. Odd, that works on my machine, gcc-16.0.1-0.7.fc45.aarch64, binutils-2.46-1.fc45.aarch64.
Ok, right its that commit I was going on about that drops the out of tree patch : https://src.fedoraproject.org/rpms/binutils/c/60fb2164e569f563d14867ef04a126b8de0835b3?branch=rawhide
Well, I don't see it with the koji build, nor a few builds I did with mainline, so back to annobin, is that 16.0.1-0.7.fc45? Maybe there is something else in the environment I switched to a clean VM yesterday to see what that did and the behavior remains consistent in rawhide.
All of them are the latest builds available from f45-build Koji tag. Jeremy, you can set "baseurl=http://kojipkgs.fedoraproject.org/repos/f45-build/latest/$basearch" in a repository definition on your system to get the exact packages. You can also look at root.log files in Koji build tasks quoted here. There are listed versions of all packages used when the the manifesting packages were built.
Big, circle but yes, if you force -g and -lto=auto and -zforce-bti then it tells you that the main.o.debug.temp.o file is missing the marking, because it is, implying that something in lto1/etc is failing to copy the eabi markings to the temp file.
The f44 and f45 gcc version of gcc is the same, so unless it is because of different configure detected assembler/linker features, they should behave the same.
(In reply to Jakub Jelinek from comment #11) > The f44 and f45 gcc version of gcc is the same, Since yesterday. This bug report is much older.
I have hit the same problem now on strongswan PR https://src.fedoraproject.org/rpms/strongswan/pull-request/34. Clearly I am not the only one. Especially suspicious it is affects only single platform on multiple upstreams.
I took Fedora 43. Upgraded it to 44. The bug is not present there because the GCC 16.0.1-0.8.fc44 is not yet in the repositories. I download and upgraded cpp, gcc, libatomic, libgcc, libgccjit, libgomp to 16.0.1-0.8.fc44 and the bug appears. Now F44 will be broken the same way as F45 once that new build gets into build root. Petr Menšík, you are not the only one. All full-arch packages built with GCC are affected. That nobody storms on devel list is because almost nobody gates Fedora builds on rpminspect results.
gcc-16.0.1-0.5.fc44 had on aarch64 in its build.log: checking assembler for support of AEABI build attributes... no while gcc-16.0.1-0.8.fc44 has checking assembler for support of AEABI build attributes... yes The support for that has been in since 2024, but gas with that support supposedly appeared in F44 only in between these. So guess libiberty/simple-object.c needs to be adjusted to also copy .ARM.attributes section.
FEDORA-2026-2e8e142d06 (gcc-16.0.1-0.9.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-2e8e142d06
FEDORA-2026-2e8e142d06 has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-2e8e142d06` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-2e8e142d06 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.