https://sourceware.org/bugzilla/show_bug.cgi?id=26314
--- Comment #5 from Alan Modra <amodra at gmail dot com> --- > https://gitlab.com/x86-gcc/gcc-bugs Thanks for that. Here are my observations about the link: gcc -O2 -g -o ar -Wl,--as-needed arparse.o arlex.o ar.o not-ranlib.o arsup.o rename.o binemul.o emul_vanilla.o bucomm.o version.o filemode.o libbfd-2.35-3.fc33.so libiberty.a -Wl,-R,. All of the above .o files are lto, leading to libbfd-2.35-3.fc33.so not being found needed when loading the IR objects. That's problem number one: We exclude IR references when deciding a shared library is needed. See PR15146. Thus none of the libbfd.so symbols are loaded before libiberty.a is scanned, and libbfd.so contains copies of libiberty.a functions. We ought to be using the libbfd.so copies rather than extracting them from the archive (an object is extracted even to satisfy IR symbols). After lto recompilation, libbfd.so is of course found to be needed and loaded. But that causes more problems. The lto recompilation didn't see symbol references from libbfd.so and variables like _xexit_cleanup are made local in the recompiled objects. Oops, two copies of them. Finally, those silly undefined symbols in the lto output debug files, combined with definitions in both libbfd.so and IR objects result in IR symbols being made dynamic. -- You are receiving this mail because: You are on the CC list for the bug.
