https://sourceware.org/bugzilla/show_bug.cgi?id=26150
--- Comment #10 from Alan Modra <amodra at gmail dot com> ---
This took a little time to recreate, mainly due to using $(wildcard ) in the
makefile. That was a bad idea, because the order of files in the archive
matters for this testcase, and apparently my file order was different to yours.
Anyway, the trigger for the ld problem here is that you used plain "ar" to
create the archive rather than "gcc-ar" or "ar --plugin ...liblto_plugin.so".
That leads to the archive map using the normal object file symbols rather than
the lto symbols, and there is a difference in the case of that quite nasty
archive0__object1.o generated from assembly.
$ aarch64-linux-nm archive0__object1.o
U archive0__object0
0000000000000000 T archive0__object1
$ aarch64-linux-gcc-nm archive0__object1.o
/usr/local/bin/../lib/gcc/aarch64-linux/11.0.0/../../../../aarch64-linux/bin/nm:
archive0__object1.o: no symbols
$ aarch64-linux-nm --plugin
/usr/local/libexec/gcc/aarch64-linux/11.0.0/liblto_plugin.so
archive0__object1.o
aarch64-linux-nm: archive0__object1.o: no symbols
So the lesson for users is to not write asm statements that define global
symbols, particularly if the C file might be compiled with -flto.
Catching this case in the linker is a pain.
--
You are receiving this mail because:
You are on the CC list for the bug.
