+++ This bug was initially created as a clone of Bug #2119380 +++ Description of problem: binutils are not able to correctly read objects and binaries compiled with "clang -flto". I tested this in RHEL-9.0 and Fedora 34+. In those environments the output is as expected. This is reproducible in every supported arch. How reproducible: 100% Steps to Reproduce: 1. echo "void lto_function(){}" | clang -flto -O2 -c -x c -o foo.o - 2. nm foo.o 3. ar crs foo.a foo.o 4. readelf -c foo.a Actual results: [root@hpe-apollo-cn99xx-14-vm-25 ~]# echo "void lto_function(){}" | clang -flto -O2 -c -x c -o foo.o - [root@hpe-apollo-cn99xx-14-vm-25 ~]# nm foo.o nm: foo.o: file format not recognized [root@hpe-apollo-cn99xx-14-vm-25 ~]# ar crs foo.a foo.o [root@hpe-apollo-cn99xx-14-vm-25 ~]# readelf -c foo.a foo.a has no archive index readelf: foo.a: Error: foo.a: unable to dump the index as none was found Expected results: $ echo "void lto_function(){}" | clang -flto -O2 -c -x c -o foo.o - $ nm foo.o 00000000 T lto_function $ ranlib foo.a foo.o ranlib: foo.o: file format not recognized $ ar crs foo.a foo.o $ readelf -c foo.a Index of archive foo.a: (1 entries, 0xe bytes in the symbol table) Contents of binary foo.a(foo.o) at offset 0x5a lto_function
Workarounds are available, so closing this BZ.