From: zimoun <zimon.toutoune@gmail.com>
To: Guillaume Le Vaillant <glv@posteo.net>
Cc: 44112@debbugs.gnu.org, Pierre Neidhardt <mail@ambrevar.xyz>
Subject: bug#44112: SBCL is not reproducible
Date: Wed, 21 Oct 2020 15:37:41 +0200 [thread overview]
Message-ID: <CAJ3okZ1i-OqjjypxYeOcqXpxzAjKVHb9NUq7Gm4FQ76K8RbCmg@mail.gmail.com> (raw)
In-Reply-To: <87wnzjzr77.fsf@yamatai>
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
next prev parent reply other threads:[~2020-10-21 13:39 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87zgcflzjn.fsf.ref@aol.com>
2020-10-21 8:12 ` bug#44112: SBCL is not reproducible zimoun
2020-10-21 12:41 ` Guillaume Le Vaillant
2020-10-21 13:37 ` zimoun [this message]
2020-10-21 13:43 ` zimoun
2020-10-21 14:32 ` Pierre Neidhardt
2020-10-21 15:13 ` zimoun
2020-10-21 16:45 ` Guillaume Le Vaillant
2020-10-21 16:55 ` Pierre Neidhardt
2020-10-22 11:19 ` zimoun
2020-10-22 12:13 ` Pierre Neidhardt
2020-10-21 14:32 ` Pierre Neidhardt
2021-01-19 16:48 ` zimoun
2021-01-23 9:19 ` Guillaume Le Vaillant
2022-11-25 17:22 ` bug#44112: Hendursaga via Bug reports for GNU Guix
2022-12-09 18:50 ` bug#44112: zimoun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJ3okZ1i-OqjjypxYeOcqXpxzAjKVHb9NUq7Gm4FQ76K8RbCmg@mail.gmail.com \
--to=zimon.toutoune@gmail.com \
--cc=44112@debbugs.gnu.org \
--cc=glv@posteo.net \
--cc=mail@ambrevar.xyz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).