bug#25629: Automake output non-deterministic when used with later Perls
Some time back I switched Perl to using a randomly seeded hash
function. (I am a core perl committer, and I do a lot of work on its
A consequence of this is that default output from tools like
Data::Dumper is non-deterministic, meaning output files under source
control, etc, change unnecessarily every time.
At least part of the automake toolset is affected, for instance autom4te.
For autom4te a simple solution is to add:
$Data::Dumper::Sortkeys = 1;
to the script. This seems to fix the problem I was observing, but an
audit of the use of the "keys" function to ensure that any such use
for output is sorted will eliminate this class of errors.
I would be happy to put together a pull request, or a patch if you
could point me to the relevant repository. (Which does not appear to
be documented in the installed versions of automake, although I may
have overlooked it.)
I am sorry I cannot give a better reproduction description than this:
while hacking the "dieharder" package I observed that after running
"autoreconf -i" that the file ./autom4te.cache/requests file changed
in ways that it should not have. Opening the file I observed it
contains output clearly from the Perl Data::Dumper module, I then made
the patch to autom4te described above, and observed that after running
"autoreconf -i" again the output was sorted, and that after running it
yet again the file was unchanged.
Classic unsorted use of undefined hash order bug that we had to do a
lot of cleanup in the Perl world around the time of Perl 5.10
bug#25629: Hrm, actually autom4te isnt part of automake, but rather autoconf.
Also I observe that there were previous patches to ensure most uses of
keys() were sorted. However not all of them, including diagnostics,
and various other places where the key order could be exposed to a
Attached is a patch that I believe fixes any remaining uses of unsorted keys.
I took the policy that automake is not performance sensitive, at least
at the level of sorting keys, and that sorting something that is not
strictly necessary does no harm.
I admit I have not been able to properly test all of these changes,
but superficial testing does not reveal any issues.
Anyway, sorry for the misleading original bug-report.