[Bug binutils/23466] Issues with Windows reproducible builds starting with commit 13e570f80cbfb299a8858ce6830e91a6cb40ab7b

[amodra at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23466

Alan Modra <amodra at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amodra at gmail dot com

--- Comment #1 from Alan Modra <amodra at gmail dot com> ---
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.

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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.