bug#44112: SBCL is not reproducible

[zimoun]

Hi,

Thank you for the explanations.

On Wed, 21 Oct 2020 at 14:42, Guillaume Le Vaillant <glv@posteo.net> wrote:

> However, some packages generate some source files at build time, usually
> containing things like data type sizes fetched from system header in
> order to use C libraries with FFI. The timestamp of a generated file
> is the current time, therefore the build is not reproducible.

This is an issue.  Do you think it is affordable to fix these
timestamps to 1970-01-01?


> IIRC, SBCL itself is built in 2 stages. First its core is compiled
> using another Common Lisp implementation (currently clisp in Guix), then
> the complete SBCL is compiled using the core compiled in stage 1. There
> is probably also an embedded timestamp issue here (coming for clisp,
> from SBCL, or both) causing the reproducibility issue.

Yes.  But I have replaced this "clisp" by ECL or by SBCL itself.
Still unreproducible.

Out-of-scope with this bug report, my aim is to have a fixed point:

 - first compile SBCL with CLISP (using the 2 stages you describe):
produce SBCL-A
 - second recompile SBCL with the previous SBCL-A (again using the 2
stages): produce SBCL-B
 - third recompile SBCL with the previous SBCL-B (again using the 2
stages): produces SBCL-C

The binary SBCL-A is not deterministic probably because of CLISP (and
CLISP should be fixed but that's another story :-)).
However, SBCL-B and SBCL-C must be deterministic.  And ideally
bit-to-bit identical but that's another story. :-)
And they are not; from my experiments at least.

Even, you could do the same procedure replacing CLISP by ECL,
producing SBCL-{A,B,C}-bis.  Then SBCL-C and SBCL-C-bis should be
bit-to-bit identical.


> Removing this source file timestamp from compiled files would simplify
> things. Maybe nothing really depends on it and it would be possible...

Thanks for the explanation.


All the best,
simon