[Reproducible-builds] Bug#797709: libmodule-build-perl: make linking order deterministic

[Niko Tyni]

Package: libmodule-build-perl
Version: 0.421400-1
Severity: wishlist
Tags: patch
Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=106813
User: reproducible-builds at lists.alioth.debian.org
Usertags: toolchain
X-Debbugs-Cc: reproducible-builds at lists.alioth.debian.org

Quoting the upstream ticket above:

   While working on the "reproducible builds" effort [0], we have noticed
   that the linking order of object files in Module::Build::c_link() depends
   on readdir() order, which is nondeterministic. This affects the generated
   binary, rendering it non-reproducible.
   
   The nondeterminism originates in rscan_dir(). The attached patch makes it
   return its file lists in sorted order. Some alternative fixes would be to
   call File::Find with the "preprocess" argument to sort the list, or sort
   the list of object files in process_support_files() or later in c_link().
   
   It's not clear to me if the latter options are safe, or if a distribution
   might inject its own list of object files and expect their order to be
   preserved. In contrast, since there's no existing guarantee of the order
   of rscan_dir() results, it's clearly safe. The downside is a number
   of probably unnecessary sort() calls when rscan_dir() gets called in
   other contexts.

   [0] https://wiki.debian.org/ReproducibleBuilds

This issue (together with other issues of its own) makes
libkinosearch1-perl non-reproducible. I suspect that having multiple
(generated?) .c files in a Build.PL distribution is unusual enough that
it explains why we haven't noticed this with other packages.

I found the disorderfs package very useful when investigating/testing
this FWIW.
-- 
Niko Tyni   ntyni at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Sort-file-lists-generated-by-rscan_dir.patch
Type: text/x-diff
Size: 1092 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20150901/6bba6874/attachment.patch>