Hi, Thank you for the explanations. On Wed, 21 Oct 2020 at 14:42, Guillaume Le Vaillant 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