[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: Efraim Flashner
Subject: bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible
Date: Sun, 13 Sep 2020 09:28:58 +0300

On Sat, Sep 12, 2020 at 07:53:04PM -0700, Chris Marusich wrote:
> 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

Is this a file we actually need during the bootstrap process? Can we
"work around it" by just deleting it?

Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

Attachment: signature.asc
Description: PGP signature

reply via email to

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