https://sourceware.org/bugzilla/show_bug.cgi?id=32846
--- Comment #5 from Michael Matz <matz at suse dot de> --- That's an interesting case. hash_new is defined in hash.o and that's inserted into both static archives, libshared.a and libkmod-internal.a, and these come in that order on the link edit command. first_hash is setup such that the first definition is known to come from libshared.a. (1) But what is and should be chosen is the second definition in libkmod-internal.a, because there's no reference to hash_new at the point where libshared.a is mentioned. The reference actually comes from within a chosen member of libkmod-internal.a in this case. So my new code that only includes a member of an archive if there isn't an earlier definition globally (in first_hash) ignores that second definition and hence doesn't include that member (and it's LTO code, so not including it in this phase means it's also not in the second phase). But in the post-LTO phase the first definition isn't chosen either (again, because the reference to hash_new only comes later), and the member that would have provided the second definition isn't there. So, undefined reference. About item (1) above: the globally first (but unchosen) definition in libshared.a is entered into first_hash via _bfd_elf_archive_symbol_lookup, at the point its mentioned, but only if this is the as-of-then first mention of that symbol (i.e. if it's already referenced by then and undefined, it's _not_ entered into first_hash). On the outset that seems strange (why would we want to enter anything not chosen into any symbol table?), but it's specifically designed to fix PR31482 and PR31489 (the raison the etre for first_hash) and not doing that fixes _this_ testcase but breaks the PR31482/31489 ones. But not consulting first_hash in the symbol-is-undefined case (which also fixes _this_ testcase) breaks the one I've added for commit 2707d55e. I'm not yet sure what the right fix is here, my gut feeling is that first_hash as-is is filled incorrectly as it globally remembers the very first definition of a symbol but that is not necessarily the one that will be used in cases when multiple archives define it and the reference comes from somewhere in the middle. Normally the linker symbol table would act correctly and the interaction with first_hash is somewhat unobvious. -- You are receiving this mail because: You are on the CC list for the bug.
