From: "Ludovic Courtès" <ludo@gnu.org>
To: Chris Marusich <cmmarusich@gmail.com>
Cc: 41669@debbugs.gnu.org, "Léo Le Bouter" <lle-bout@zaclys.net>,
"Maxim Cournoyer" <maxim.cournoyer@gmail.com>,
"Vincent Legoll" <vincent.legoll@gmail.com>
Subject: bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible
Date: Mon, 14 Dec 2020 09:36:09 +0100 [thread overview]
Message-ID: <874kkoyebq.fsf@gnu.org> (raw)
In-Reply-To: <87pn3dth0l.fsf_-_@gmail.com> (Chris Marusich's message of "Sun, 13 Dec 2020 15:36:58 -0800")
Hi Chris,
Chris Marusich <cmmarusich@gmail.com> skribis:
> It's been almost half a year now, and we're not really any closer to
> figuring out why the cross-built GCC bootstrap binary is
> non-reproducible. It seems counter-productive to obsess about making
> this specific binary reproducible, although I wish it could be so.
>
> What do you think about using the bootstrap binaries we built half a
> year ago, and proceed with bootstrapping efforts? To be totally honest,
> I'm feeling pretty exhausted by this bug, since I have spent so many
> days trying to unravel it, and I haven't made any significant progress.
> With no clear end in sight, I would really prefer to move on instead of
> blocking the entire bootstrapping effort on this reproducibility bug.
> The reproducibility of the bootstrap binaries is important, but simply
> having any bootstrap binaries at all is also important. I think I have
> done my due diligence to try making them reproducible. Most of them
> are, but I just can't figure out why GCC isn't. I think it would be
> best to proceed with the binaries we have.
I didn’t follow the whole discussion nor did I try to investigate
myself, but thanks a lot for going to great lengths trying to identify
the issue; this is an impressive amount of work, and I can only share
your disappointment.
Given this effort, I agree that it may be best at this point to move on
and start with these non-reproducible binaries. At least, the problem
is now documented.
> At this point, it might even make more sense to try bootstrapping for
> powerpc64le instead of powerpc64, since the rest of the world seems to
> be gravitating toward the little-endian variant on POWER9 hardware, and
> thus various programs out there are more likely to be better tested on
> powerpc64le than powerpc64.
Yes, my understanding is that other people, in particular Tobias Platen
and dftxbs3e, were looking at powerpc64le, so perhaps it’s a good idea
to concentrate on that one?
Anyhow, please let me know if/when bootstrap binaries should be uploaded
to ftp.gnu.org (with a signed message). When updating bootstrap.scm to
refer to them, please include the commit ID used to build them in the
commit message.
Thanks,
Ludo’.
next prev parent reply other threads:[~2020-12-14 8:37 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-02 18:59 bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible Chris Marusich
2020-06-03 9:48 ` Chris Marusich
2020-06-03 20:50 ` Vincent Legoll
2020-06-10 6:15 ` Chris Marusich
2020-06-10 22:20 ` Bengt Richter
2020-06-11 21:09 ` Jack Hill
2020-09-13 2:53 ` Chris Marusich
2020-09-13 6:28 ` Efraim Flashner
2020-09-26 6:52 ` Chris Marusich
2020-10-05 12:33 ` Ludovic Courtès
2020-12-13 23:36 ` Chris Marusich
2020-12-14 8:17 ` Efraim Flashner
2020-12-14 8:36 ` Ludovic Courtès [this message]
2020-12-14 9:22 ` Leo Le Bouter via Bug reports for GNU Guix
2020-12-14 10:27 ` Efraim Flashner
2020-12-14 10:34 ` Leo Le Bouter via Bug reports for GNU Guix
2020-12-14 10:38 ` Efraim Flashner
2020-12-14 10:44 ` Leo Le Bouter via Bug reports for GNU Guix
2020-12-14 22:24 ` Ludovic Courtès
2020-12-15 7:34 ` Leo Le Bouter via Bug reports for GNU Guix
2020-12-15 9:35 ` Leo Le Bouter via Bug reports for GNU Guix
2020-12-15 7:46 ` Leo Le Bouter via Bug reports for GNU Guix
2020-12-20 7:28 ` Chris Marusich
2020-12-28 2:25 ` Leo Le Bouter via Bug reports for GNU Guix
2020-12-28 4:23 ` Chris Marusich
2020-12-28 8:07 ` Efraim Flashner
2020-12-28 12:39 ` Leo Le Bouter via Bug reports for GNU Guix
2020-12-28 12:55 ` Leo Le Bouter via Bug reports for GNU Guix
2020-12-28 15:31 ` Leo Le Bouter via Bug reports for GNU Guix
2020-12-28 17:40 ` Leo Le Bouter via Bug reports for GNU Guix
2020-12-28 19:01 ` Leo Le Bouter via Bug reports for GNU Guix
2020-12-28 20:59 ` Leo Le Bouter via Bug reports for GNU Guix
2020-12-29 7:08 ` Efraim Flashner
2021-01-05 3:54 ` Chris Marusich
2020-12-28 8:07 ` Efraim Flashner
2020-12-30 1:28 ` Leo Le Bouter via Bug reports for GNU Guix
2021-01-04 9:37 ` Ludovic Courtès
2021-01-04 11:16 ` Efraim Flashner
2021-01-05 3:15 ` Chris Marusich
2021-01-06 8:59 ` Ludovic Courtès
2021-01-11 10:31 ` Chris Marusich
2021-01-21 6:26 ` Chris Marusich
2021-01-31 21:35 ` Ludovic Courtès
2020-10-05 12:47 ` Efraim Flashner
2021-02-27 2:39 ` Chris Marusich
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=874kkoyebq.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=41669@debbugs.gnu.org \
--cc=cmmarusich@gmail.com \
--cc=lle-bout@zaclys.net \
--cc=maxim.cournoyer@gmail.com \
--cc=vincent.legoll@gmail.com \
/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).