https://sourceware.org/bugzilla/show_bug.cgi?id=23466
--- Comment #2 from Nicolas Vigier <boklm at torproject dot org> --- (In reply to Alan Modra from comment #1) > The commit message for 13e570f80cb says "See the comment which I'm removing > from elf_link_add_archive_symbols." That's this comment: > > /* Add symbols from an ELF archive file to the linker hash table. We > - don't use _bfd_generic_link_add_archive_symbols because of a > - problem which arises on UnixWare. The UnixWare libc.so is an > - archive which includes an entry libc.so.1 which defines a bunch of > - symbols. The libc.so archive also includes a number of other > - object files, which also define symbols, some of which are the same > - as those defined in libc.so.1. Correct linking requires that we > - consider each object file in turn, and include it if it defines any > - symbols we need. _bfd_generic_link_add_archive_symbols does not do > - this; it looks through the list of undefined symbols, and includes > - any object file which defines them. When this algorithm is used on > - UnixWare, it winds up pulling in libc.so.1 early and defining a > - bunch of symbols. This means that some of the other objects in the > - archive are not included in the link, which is incorrect since they > - precede libc.so.1 in the archive. > + don't use _bfd_generic_link_add_archive_symbols because we need to > + handle versioned symbols. > > So... Commit 13e570f80cb may change the order in which files are extracted > from archives, which in turn can change the set of files extracted from > archives. Is that the case for your build? Link with -Wl,-t to see. Thanks. I will try a build using -Wl,-t to see if I can get more details about the issue. > > Also, you say "When running objdump -x on 2 builds of the same dll file". > Were the two builds comparing builds using different versions of the linker? > If so, it is quite possible that the output will differ. I meant two builds done using the same linker version (the same binutils commit), as it is expected that different binutils versions could produce different outputs. When we are doing two Tor Browser builds using a binutils commit before 13e570f80cbfb2, we get the same output in both builds. When we do two Tor Browser builds using 13e570f80cbfb2 or a later binutils commit, we get a different output in the two builds (although we used the same binutils commit in both builds). -- 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
