[Top][All Lists]

[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

- 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

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.


Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]