https://sourceware.org/bugzilla/show_bug.cgi?id=24567
--- Comment #3 from Alan Modra <amodra at gmail dot com> --- I reproduced the problem using gcc-8 and openssl from git. The problem here is caused by libcrypto-lib-armcap.o being loaded twice. So why did that happen? Well, ld sets a flag for object files loaded from the command line that prevents the object being loaded twice (that's assuming you don't deliberately mention the object file twice). For object files within archives, ld relies on the symbols defined by a particular object file staying defined, so that another search of the archive armap won't find undefined symbols satisfied by that object. Depending on the target, ld also extracts object files that provide definitions for common symbols. Again ld expects that a symbol won't go from defined back to common, but that was exactly what happened. libcrypto-lib-armcap.o was a -flto object that defined OPENSSL_armcap_P. libcrypto-lib-sha1-armv8.o also defined OPENSSL_armcap_P but as a common symbol, and this file, being from assembly source, wasn't a -flto object. The rules for merging -flto IR symbols and normal object file symbols are a little complicated, with normal object file symbols generally taking precedence. In this case though, ld wrongly overrode the definition from the IR object with the common symbol from libcrypto-lib-sha1-armv8.o. A second search of the archive thus saw libcrypto-lib-armcap.o providing a definition for a common symbol. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
