From: Chris Marusich <cmmarusich@gmail.com>
To: 41669@debbugs.gnu.org
Cc: "Vincent Legoll" <vincent.legoll@gmail.com>,
"Léo Le Bouter" <lle-bout@zaclys.net>,
"Maxim Cournoyer" <maxim.cournoyer@gmail.com>
Subject: bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible
Date: Sat, 12 Sep 2020 19:53:04 -0700 [thread overview]
Message-ID: <87a6xu2xrj.fsf@gmail.com> (raw)
In-Reply-To: <87y2p4mqe2.fsf@gmail.com> (Chris Marusich's message of "Wed, 03 Jun 2020 02:48:21 -0700")
[-- Attachment #1: Type: text/plain, Size: 3320 bytes --]
Hi everyone,
Chris Marusich <cmmarusich@gmail.com> writes:
> If you examine the derivations and their inputs, you'll find that they
> depend upon each other in the following order:
>
> guix build --target=powerpc64-linux-gnu -d -e '(@ (gnu packages make-bootstrap) %gcc-bootstrap-tarball)'
> /gnu/store/pygln3lr6qbxcps3kmn3w4bc0d0nlpd3-gcc-stripped-tarball-5.5.0.drv
>
> guix build --target=powerpc64-linux-gnu -d -e '(@@ (gnu packages make-bootstrap) %gcc-stripped)'
> /gnu/store/kcv3ja1rfr93hw6ly51878zjhdwpgv7z-gcc-stripped-5.5.0.drv
>
> guix build --target=powerpc64-linux-gnu -d -e '(@@ (gnu packages make-bootstrap) %gcc-static)'
> /gnu/store/m9hfwppla8lph0vxa15lfkp81s2bbjjs-gcc-static-5.5.0.drv
>
> In other words, gcc-static-5.5.0.drv is an input of
> gcc-stripped-5.5.0.drv, which is an input of
> gcc-stripped-tarball-5.5.0.drv. Above, I've included example guix
> commands you can use to obtain each derivation. Using "guix build
> --check", I confirmed that all three of these derivations build
> reproducibly on my machine.
After further experimentation, I've discovered that %gcc-static, when
built as shown above (without the -d option, of course), produces
different output on Debian than on Fedora.
Specifically, the %gcc-static output contains a file named libstdc++.a.
This file is an archive file. Although its members are
content-identical in the case of Fedora and Debian, the order of the
members in the archive differs. Because the exact same inputs were
used, it seems very likely that a difference in the Guix build
environment caused the %gcc-static build logic to order the members of
libstdc++.a differently.
I built %gcc-static using Guix commit
a02b2f8b86c0227eb69aa24b4373aef456365334. Both Debian and Fedora were
x86_64-linux systems. I took the following steps to make absolutely
certain that the exact same inputs were used on Debian and Fedora:
- I provisioned two fresh EC2 instances (Debian and Fedora).
- I installed Guix on Debian.
- I did "guix pull" on Debian to get to the aforementioned commit.
- I built %gcc-static on Debian as indicated above.
- I manually copied the Guix store and the Guix database from Debian to
Fedora.
- I manually fixed up Fedora so it could run Guix (I created the guix
users, added a systemd unit file, disabled selinux, etc.).
- I manually verified the Guix version and the store contents were
identical on Fedora and Debian.
- I GC'd %gcc-static (and nothing else) on Fedora.
- I rebuilt %gcc-static on Fedora.
- I compared the Fedora %gcc-static output to the Debian %gcc-static
output.
The %gcc-static package uses GCC 5.5.0 as its source. I got a copy of
the GCC 5.5.0 source code, and I looked at it. However, it's complex.
I can't pinpoint where they actually build the libstdc++.a file. Can
anyone point me to the code that does this in the GCC 5.5.0 source? I
expected to find the logic hiding in a makefile or a configure script or
something, but I haven't found it yet.
Since this is an old GCC, it is possible that this was a known
reproducibility bug which has since been fixed. I haven't looked into
that possibility yet. If that's the case, though, it would be nice
because we could simply backport a fix.
--
Chris
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2020-09-13 2:54 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 [this message]
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
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=87a6xu2xrj.fsf@gmail.com \
--to=cmmarusich@gmail.com \
--cc=41669@debbugs.gnu.org \
--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).