Re: emacs reproducible builds part1 of 2 : eln

[Andrea Corallo]

"Bernhard M. Wiedemann" <bernhardout@lsmod.de> writes:

> On 11/02/2024 11.24, Andrea Corallo wrote:
>> Andrea Corallo <acorallo@gnu.org> writes:
>> 
>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>
>>>>>> So, I'm not sure it explains the phenomenon you're seeing (I haven't
>>>>>> seen the rest of this thread yet).
>>>>>
>>>>> Interesting, I imagined the walk order is defined but my question is
>>>>> what about two hash table with the same content but created in two
>>>>> different sessions?
>>>>
>>>> Depends how they were filled: if they were filles by the same sequence
>>>> of operations, then they should have the same walk-order.
>>>> If not, then all bets are off.
>>>
>>> Okay that's good news, I'll investigate more tomorrow, the case is
>>> pretty well defined now so should be possible to understand exactly what
>>> is going on.
>> Okay cool I pushed a fix in emacs29, with that installed we don't
>> try to
>> sort anymore conses based on their 'sxhash-equal' value because this is
>> not stable over different Emacs sessions.  With the change installed the
>> build looks finally reproducible here.
>> Bernhard please let us know if this solves the problem on your side
>> as
>> well.
>
> Thanks for the fix.
> I had missed the email and only now got to retest.
> I found your commit
> 614b244a7fa03fcb27d76757e14ef0fa895d6f23
> is part of emacs-29.3 and the x-win.el compilation is now deterministic.
>
> The bad news is that there are still 4 more non-deterministic .eln files.
> I made a reproducer for one of them:
>
> cd ~/rpmbuild/BUILD/emacs-29.3/native-lisp &&
>  for i in $(seq 10) ; do
>   ../src/emacs -batch \
>   --eval "(batch-native-compile t)" ../lisp/international/utf7.el &&
>   md5sum 29.*/utf7.eln
>  done | sort | uniq -c
>
> again with ASLR as factor in the result.
>
> The varying files are
> emacs/29.3/native-lisp/29.3-f8a6a23e/el-72f9fa70-1a554ff6.eln
> emacs/29.3/native-lisp/29.3-f8a6a23e/ox-9aa46d10-040d281c.eln
> emacs/29.3/native-lisp/29.3-f8a6a23e/utf7-8aab9346-0cfd2c82.eln
> emacs/29.3/native-lisp/29.3-fc431f4a/utf7-8aab9346-0cfd2c82.eln
>
> Unfortunately, the el.el and ox.el don't reproduce non-determinism the
> same way.

Just an ACK that I've reproduced the utf7 case and I'm working on a fix.
I'll look at the other afterwards (if the fix does not fix all of them).

Thanks

  Andrea