[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reprodu
From: |
Chris Marusich |
Subject: |
bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible |
Date: |
Sat, 12 Sep 2020 19:53:04 -0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
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
signature.asc
Description: PGP signature
- bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible,
Chris Marusich <=