For me at least winepulse. drv and winealsa. drv are in content exactly identical. Maybe this could be a side-effect of reproducible builds? Here the hashes aren't identical for those two libraries
and winealsa.drv are in content exactly identical.
Maybe this could be a side-effect of reproducible builds? Here the hashes aren't identical for those two libraries
Probably, yes - in PE builds, the binaries would not be exactly identical, because https://gitlab.winehq.org/wine/wine/-/commit/b0908666639d5dfe825b5d5f3b9893b... was only a partial fix. Winebuild writes the export table with a reproducible hash (of the filename) to produce the export table timetime, but mingw-ld from binutils still introduces a duplicate export table (named "dll stuff" if you add -Wl,-Map=) that gets populated at https://github.com/bminor/binutils-gdb/blob/f86c456bec7969779dd044c313e419f8...
This is just junk data, but it ends up in the file following the one generated by winebuild that readers actually use. Now that winegcc uses Wl,--exclude-all-symbols this extra table now has zero symbols in it, but it still makes a duplicate export directory table, but that header still has a timestamp in it https://github.com/bminor/binutils-gdb/blob/f86c456bec7969779dd044c313e419f8...
However, NixOS is all about reproducible builds, so I'd expect their binutils to use SOURCE_DATE_EPOCH. --no-insert-timestamp, or something, like that to remove the BFD timestamps in general, and then one might get identical binaries.
I dug into this at one point curious about the large/non-reproducible .edata section, found !3173, but decided the few remaining bytes of "dll stuff" junk data were basically harmless, so I never bothered to report it... but it seems topical to this thread. Certainly I think we'd rather not have the duplicate export directory table, if there was some way to get binutils to skip producing it. But there doesn't seem to be anything obvious...
Public