SBCL is not reproducible

  • Open
  • quality assurance status badge
Details
4 participants
  • Guillaume Le Vaillant
  • Hendursaga
  • Pierre Neidhardt
  • zimoun
Owner
unassigned
Submitted by
zimoun
Severity
normal
Z
Z
zimoun wrote on 21 Oct 2020 10:12
(address . bug-guix@gnu.org)
86o8kw80bl.fsf@gmail.com
Dear,

Using Guix 58af4c9, the package ’sbcl’ seems not-reproducible.

The output of “guix challenge” is:

Toggle snippet (32 lines)
differing files:
/lib/sbcl/contrib/sb-rt.fasl
/lib/sbcl/contrib/uiop.fasl
/lib/sbcl/contrib/sb-cover.fasl
/lib/sbcl/contrib/sb-capstone.fasl
/lib/sbcl/contrib/sb-executable.fasl
/lib/sbcl/contrib/sb-bsd-sockets.fasl
/lib/sbcl/contrib/sb-simple-streams.fasl
/lib/sbcl/contrib/sb-queue.fasl
/lib/sbcl/contrib/sb-gmp.fasl
/lib/sbcl/contrib/sb-aclrepl.fasl
/lib/sbcl/contrib/sb-sprof.fasl
/lib/sbcl/contrib/sb-grovel.fasl
/lib/sbcl/contrib/sb-posix.fasl
/lib/sbcl/contrib/asdf.fasl
/lib/sbcl/contrib/sb-mpfr.fasl
/lib/sbcl/contrib/sb-cltl2.fasl
/lib/sbcl/contrib/sb-concurrency.fasl
/lib/sbcl/contrib/sb-md5.fasl
/lib/sbcl/contrib/sb-introspect.fasl
/lib/sbcl/contrib/sb-rotate-byte.fasl
/lib/sbcl/sbcl.core
/bin/sbcl
/share/sbcl/src/runtime/coreparse.o
/share/sbcl/src/runtime/sbcl

1 store items were analyzed:
- 0 (0.0%) were identical
- 1 (100.0%) differed
- 0 (0.0%) were inconclusive

which is confirmed by the experimental Data Service webpage:



I do not know if the patches in ’staging’ will fix this.

Note that this issue does not imply that the build system
’asdf-build-system/sbcl’ is or will be not reproducible. However, this
issues cuts any Diverse Double Compiling attempt.

All the best,
simon
G
G
Guillaume Le Vaillant wrote on 21 Oct 2020 14:41
(name . zimoun)(address . zimon.toutoune@gmail.com)
87wnzjzr77.fsf@yamatai
zimoun <zimon.toutoune@gmail.com> skribis:

Toggle quote (10 lines)
> Using Guix 58af4c9, the package ’sbcl’ seems not-reproducible.
>
> [...]
>
> I do not know if the patches in ’staging’ will fix this.
>
> Note that this issue does not imply that the build system
> ’asdf-build-system/sbcl’ is or will be not reproducible. However, this
> issues cuts any Diverse Double Compiling attempt.

IIRC, when compiling, SBCL puts the timestamp of the source file in the
compiled file. It's not a problem when just doing basic compilation
because the source files' timestamps have been set to "1970-01-01".

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.

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.

The patches currently in the staging branch don't have any effect on
the generation of source files or on the format of the compiled files,
so they will not help with this issue.

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

iIUEAREKAC0WIQTLxZxm7Ce5cXlAaz5r6CCK3yH+PwUCX5AsjA8cZ2x2QHBvc3Rl
by5uZXQACgkQa+ggit8h/j9+WwD+NUWl7DQqk48V2PntLTM52xYfpmiBplWDSMrC
LBPgUYoA/1/e0p1lr5TV7cG9BJSmZzTHBubCEHDSIaRRyproDyuo
=M569
-----END PGP SIGNATURE-----

Z
Z
zimoun wrote on 21 Oct 2020 15:37
(name . Guillaume Le Vaillant)(address . glv@posteo.net)
CAJ3okZ1i-OqjjypxYeOcqXpxzAjKVHb9NUq7Gm4FQ76K8RbCmg@mail.gmail.com
Hi,

Thank you for the explanations.

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

Toggle quote (5 lines)
> 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?


Toggle quote (6 lines)
> 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.


Toggle quote (3 lines)
> 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
Z
Z
zimoun wrote on 21 Oct 2020 15:43
Re: bug#44112: SBCL is not reproducible
(name . Guillaume Le Vaillant)(address . glv@posteo.net)
CAJ3okZ1z0=jp8b=g4bqq=_=2yJk-z+McJ8PVcdy00cY2nwcyjg@mail.gmail.com
On Wed, 21 Oct 2020 at 15:39, zimoun <zimon.toutoune@gmail.com> wrote:

Toggle quote (6 lines)
> > 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.

In addition, GCC is also involved in the party. And I have also
replaced it by Clang with the same effect.

Cheers,
simon
P
P
Pierre Neidhardt wrote on 21 Oct 2020 16:32
(address . 44112@debbugs.gnu.org)
87y2jzzm3d.fsf@ambrevar.xyz
zimoun <zimon.toutoune@gmail.com> writes:

Toggle quote (3 lines)
> In addition, GCC is also involved in the party. And I have also
> replaced it by Clang with the same effect.

Where?

--
Pierre Neidhardt
-----BEGIN PGP SIGNATURE-----

iQFGBAEBCAAwFiEEUPM+LlsMPZAEJKvom9z0l6S7zH8FAl+QRmcSHG1haWxAYW1i
cmV2YXIueHl6AAoJEJvc9Jeku8x/iUEH/j0PGRqFHvUFRCVpmoyk/pZ+NOnBsLqE
7hbPN9ab3bed4PWF/oiEOAsX7bX2BMnYr0nFIMEreRtgqGsOq8R4xet7ERNr2pqr
er2RHfQBdig/VuGpVFxHO6wd1UlRU+MTS/ma8rN7imzEF5CriYImmExXs7RYV9EX
4g2YDL4+7ksdgz2CGHh1bu8trs/PvJuN4p+V4/s512hxqJ8k08shTK8iq0NEivh8
bPUgB4zCVICt+g2x2XSASb4rifGOTArOGBsECiolYsydtWmgyYW+DN0KMhj8QKsn
p+rmooTyQDYt/BsMYXd5q/WVFgpsM37N0SnHzqO6dmX3BYPFeEvMisc=
=Wdr8
-----END PGP SIGNATURE-----

P
P
Pierre Neidhardt wrote on 21 Oct 2020 16:32
Re: SBCL is not reproducible
(address . 44112@debbugs.gnu.org)
87v9f3zm2t.fsf@ambrevar.xyz
Guillaume Le Vaillant <glv@posteo.net> writes:

Toggle quote (4 lines)
> 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.

Yes, this is correct.

--
Pierre Neidhardt
-----BEGIN PGP SIGNATURE-----

iQFGBAEBCAAwFiEEUPM+LlsMPZAEJKvom9z0l6S7zH8FAl+QRnoSHG1haWxAYW1i
cmV2YXIueHl6AAoJEJvc9Jeku8x/QpAH/jDzZbTf5c7Q9zoLt1O/TGkZkDfIXxqV
g/mM32PO9o1w9oSepAHxSC3uubcXi+kx7FhIdOhHKKFOtARx+mqTElH5qq1N3OGs
AaKDEuy6lPY/kijbEHsy1FHZw5Swvww6Vf0qwHkp8CFFGdr9jEh57LMf1TQ1T+hc
pWbUJ9yAuVhNUhX0Fa82cqiah0dB9QWO0/NXPM9VZU5asvs1Yt1DzreeAVpFFb/e
6OZYfq/q3nlBNYyORupj1aN+Z4+aUr4kr6L9CvmKb+Yy/cJJd5fUIsjgt09QcWem
JZrQ/3I6/MUhJgMxY7xr2L/IIZ3VFm6C2wrcg5DReMOofb/MxJ71DGM=
=0cXn
-----END PGP SIGNATURE-----

Z
Z
zimoun wrote on 21 Oct 2020 17:13
Re: bug#44112: SBCL is not reproducible
(name . Pierre Neidhardt)(address . mail@ambrevar.xyz)
CAJ3okZ1UC3fXedXOkU=cwRQ6Tv_iy7xK3xUKtWbND2HBpaUwBA@mail.gmail.com
On Wed, 21 Oct 2020 at 16:32, Pierre Neidhardt <mail@ambrevar.xyz> wrote:

Toggle quote (5 lines)
> > In addition, GCC is also involved in the party. And I have also
> > replaced it by Clang with the same effect.
>
> Where?

Toggle snippet (66 lines)
(define-module (ddc-sbcl)
#:use-module (guix packages)
#:use-module (guix utils)
#:use-module ((guix build utils) #:select (modify-phases))
#:use-module (srfi srfi-1)
#:use-module (ice-9 match)

#:use-module (gnu packages lisp)
#:use-module (gnu packages commencement)
#:use-module (gnu packages llvm))

(define (make-sbcl name string-compil compil cc)
(package
(inherit sbcl)
(name name)
(arguments
(substitute-keyword-arguments (package-arguments sbcl)
((#:phases phases)
`(modify-phases ,phases
(replace 'build
(lambda* (#:key outputs #:allow-other-keys)
(setenv "CC" ,cc)
(invoke "sh" "make.sh" ,string-compil
(string-append "--prefix="
(assoc-ref outputs "out"))
"--dynamic-space-size=2Gb"
"--with-sb-core-compression"
"--with-sb-xref-for-internals")))))))
(native-inputs
`(,@(alist-delete "clisp" (package-native-inputs sbcl))
("compil" ,compil)))))


(define-public sbcl-A
(package-with-c-toolchain
(make-sbcl "sbcl-A" "clisp" clisp "gcc")
`(("gcc" ,gcc-toolchain)))) ;fail with 6

(define-public sbcl-B
(package-with-c-toolchain
(make-sbcl "sbcl-B" "ecl" ecl "clang")
`(("clang" ,clang-toolchain))))



(define-public sbcl-AA
(package-with-c-toolchain
(make-sbcl "sbcl-AA" "sbcl" sbcl-A "gcc")
`(("gcc" ,gcc-toolchain))))

(define-public sbcl-BB
(package-with-c-toolchain
(make-sbcl "sbcl-BB" "sbcl" sbcl-B "clang")
`(("clang" ,clang-toolchain))))


(define-public sbcl-CC
(package-with-c-toolchain
(make-sbcl "sbcl-CC" "sbcl" sbcl-A "clang")
`(("clang" ,clang-toolchain))))

(define-public sbcl-DD
(package-with-c-toolchain
(make-sbcl "sbcl-DD" "sbcl" sbcl-B "gcc")
`(("gcc" ,gcc-toolchain))))
G
G
Guillaume Le Vaillant wrote on 21 Oct 2020 18:45
(name . zimoun)(address . zimon.toutoune@gmail.com)
87r1przfwo.fsf@yamatai
zimoun <zimon.toutoune@gmail.com> skribis:

Toggle quote (5 lines)
>> 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.

A developer of SBCL agrees that the timestamp should be removed [1], but
currently Slime has a function depending on it. I asked if this could
be fixed [2]. We'll see...

-----BEGIN PGP SIGNATURE-----

iIUEAREKAC0WIQTLxZxm7Ce5cXlAaz5r6CCK3yH+PwUCX5Bltw8cZ2x2QHBvc3Rl
by5uZXQACgkQa+ggit8h/j/HgAD/UNRHvLALDFFdm71pw9wUxnTaLnrAzy//ifOO
O+ZuRroA/1U01XRKLlVACRVGA+xqEj0LDgY9iED5rJx0+hIZTVA4
=Rmx0
-----END PGP SIGNATURE-----

P
P
Pierre Neidhardt wrote on 21 Oct 2020 18:55
(address . 44112@debbugs.gnu.org)
87imb334dv.fsf@ambrevar.xyz
Guillaume Le Vaillant <glv@posteo.net> writes:

Toggle quote (7 lines)
> A developer of SBCL agrees that the timestamp should be removed [1], but
> currently Slime has a function depending on it. I asked if this could
> be fixed [2]. We'll see...
>
> [1] https://sourceforge.net/p/sbcl/mailman/message/37133640/
> [2] https://github.com/slime/slime/issues/583

Thank you so much for asking!

--
Pierre Neidhardt
-----BEGIN PGP SIGNATURE-----

iQFGBAEBCAAwFiEEUPM+LlsMPZAEJKvom9z0l6S7zH8FAl+QaAwSHG1haWxAYW1i
cmV2YXIueHl6AAoJEJvc9Jeku8x/31wH/3LA595p9lpR88NvU9D6a9sC3Xkp2FWq
n8QP+ZV/OLJ5CYR5yveGhgegs73S65IYpTxC1ZezowGkZzfbU6mHnBO2FJV6Wl8E
R8WJaAzxhxRjNy1TL46tViBY5PQ6QniyIw3lyAwI38VAoch9z4ykEKRIh7ex5/qK
/iKcv0rSNNxCqLDFgob//t+aPY4E4NaYpumtCOpx4bUQp0jECyVuikU1QfkqmQBm
VQ/45m/s5B26G+Xs6pYYQ/zTub3/mxcEszi3+ttnCfCsu0Q7r1vDQe9Ge1hE/riH
LIZM1JRag3iyRrgR7mh5g251EiWgyLG6usCKmCjWcNkj8On2yjYiwVI=
=MonO
-----END PGP SIGNATURE-----

Z
Z
zimoun wrote on 22 Oct 2020 13:19
(name . Guillaume Le Vaillant)(address . glv@posteo.net)
CAJ3okZ3_oSeEBgrKxKKevch39KGHF0Orkyqqk9m5on2VwQNbTw@mail.gmail.com
Hi Guillaume,

Thank you for asking upstream.


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

Toggle quote (6 lines)
> A developer of SBCL agrees that the timestamp should be removed [1], but
> currently Slime has a function depending on it. I asked if this could
> be fixed [2]. We'll see...
>
> [1] https://sourceforge.net/p/sbcl/mailman/message/37133640/

Ouch! Hard to read when not subscribed. :-)

Toggle quote (2 lines)
If upstream does not want to patch, do you think it is doable to patch
SLIME and maintain the patch with the Guix package?

Thanks,
simon
P
P
Pierre Neidhardt wrote on 22 Oct 2020 14:13
(address . 44112@debbugs.gnu.org)
87k0vi4fwi.fsf@ambrevar.xyz
zimoun <zimon.toutoune@gmail.com> writes:

Toggle quote (3 lines)
> If upstream does not want to patch, do you think it is doable to patch
> SLIME and maintain the patch with the Guix package?

Accepted or not, we also need to ping the SLY maintainer to apply the
same change. (SLY is a fork of SLIME.)

--
Pierre Neidhardt
-----BEGIN PGP SIGNATURE-----

iQFGBAEBCAAwFiEEUPM+LlsMPZAEJKvom9z0l6S7zH8FAl+Rd30SHG1haWxAYW1i
cmV2YXIueHl6AAoJEJvc9Jeku8x/NDUH/AomtzDBS811zh0aF3ZCCrLBabxP5ifq
pJh0aZ9SeiUqEs/YdN5wkItFnMksI27lf7LXAzK7bh1z+oacE/lraViEc3tP5GMg
8DIBdzxYOaSVd5cpbP0rocReOAl5pXyJBC7k33/8Kg9PVelY10ZGa03QsnEQb7xM
6YdAXYP1hAaUvOc+gNAyJIfP8oRKxP5Iy2gUspyNInObfA5rMHAC5TtavIDJV3kU
i562EOWsS3OBTtzTg7oKwdEj4/9muL/J5BfGlnxPT5yLQNZ3DRnWW3QCLVS+2c3w
M81rmXAa3qd8y5n4cOmvZ0iJ9t3KJ7/sLFFSHWANj6i71CU9i3xZxKo=
=lOkM
-----END PGP SIGNATURE-----

Z
Z
zimoun wrote on 19 Jan 2021 17:48
(name . Guillaume Le Vaillant)(address . glv@posteo.net)
86r1mg98la.fsf@gmail.com
Hi,

On Wed, 21 Oct 2020 at 14:41, Guillaume Le Vaillant <glv@posteo.net> wrote:
Toggle quote (4 lines)
> zimoun <zimon.toutoune@gmail.com> skribis:
>
>> Using Guix 58af4c9, the package ’sbcl’ seems not-reproducible.

[...]

Toggle quote (3 lines)
> Removing this source file timestamp from compiled files would simplify
> things. Maybe nothing really depends on it and it would be possible...

Any news from upstream? Still unreproducible for me.


All the best,
simon
G
G
Guillaume Le Vaillant wrote on 23 Jan 2021 10:19
(name . zimoun)(address . zimon.toutoune@gmail.com)
874kj8ko2e.fsf@yamatai
zimoun <zimon.toutoune@gmail.com> skribis:

Toggle quote (18 lines)
> Hi,
>
> On Wed, 21 Oct 2020 at 14:41, Guillaume Le Vaillant <glv@posteo.net> wrote:
>> zimoun <zimon.toutoune@gmail.com> skribis:
>>
>>> Using Guix 58af4c9, the package ’sbcl’ seems not-reproducible.
>
> [...]
>
>> Removing this source file timestamp from compiled files would simplify
>> things. Maybe nothing really depends on it and it would be possible...
>
> Any news from upstream? Still unreproducible for me.
>
>
> All the best,
> simon

So far Slime still uses the function getting the source file timestamp,
so these timestamps can't be removed from SBCL.
A patch for Slime would be accepted (see [2]), but as far as I know
nobody has worked on it yet.

-----BEGIN PGP SIGNATURE-----

iIUEAREKAC0WIQTLxZxm7Ce5cXlAaz5r6CCK3yH+PwUCYAvqKQ8cZ2x2QHBvc3Rl
by5uZXQACgkQa+ggit8h/j+WYgD/U5Pvxf1b08a5766PhJYlnBeD9rT6rRXaMoGa
mbGi5pIA/iGkqIHaAr7lzuKm+PHRtmkyJNTh3VLtymrt5Jyx2aoY
=HZ/Z
-----END PGP SIGNATURE-----

H
Z
Z
zimoun wrote on 9 Dec 2022 19:50
(address . glv@posteo.net)
87k030pg1u.fsf@gmail.com
Hi,

Thank you for the follow up.

On Fri, 25 Nov 2022 at 12:22, Hendursaga via Bug reports for GNU Guix <bug-guix@gnu.org> wrote:
Toggle quote (4 lines)
> The patch[1] has been closed for some time, is there any other pending patches blocking going forward?
>
> [1] https://github.com/slime/slime/issues/583

Indeed, but the package sbcl is not yet reproducible. The remaining
issue is about PDF.

Using Guix 28d1e51, I get:

Toggle snippet (4 lines)
$ diff -r --no-dereference /gnu/store/0q9z6j5ml4rkfrg57axznasdjfm7x803-sbcl-2.2.11-doc{,-check}
Binary files /gnu/store/0q9z6j5ml4rkfrg57axznasdjfm7x803-sbcl-2.2.11-doc/share/doc/sbcl/sbcl.pdf and /gnu/store/0q9z6j5ml4rkfrg57axznasdjfm7x803-sbcl-2.2.11-doc-check/share/doc/sbcl/sbcl.pdf differ

Cheers,
simon
?