bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Chris Marusich]

Hi,

Chris Marusich  writes:

> Going forward, I'm not sure how best to investigate the inputs to find
> out what's causing the differences.  I just know I really, really,
> really don't want to rebuild everything multiple times, since it takes
> hours/days.  If you have any creative ideas for how to speed up the
> investigation, I'm all ears.

I've analyzed the graph of derivations that produce differing output
across machines.  Here's an image of the graph:


And here is the GraphViz source, which you can render however you want:

digraph "Differing Derivations" {

"/gnu/store/07bd5ll0adnyrv1zaz11vz2x1ax447ka-glibc-mesboot-2.16.0.drv" [label = "glibc-mesboot-2.16.0", shape = box, fontname = sans]
"/gnu/store/0zkiqxwm6k637xr5s1690nwllnvybvyw-xz-mesboot-5.0.0.drv" [label = "xz-mesboot-5.0.0", shape = box, fontname = sans]
"/gnu/store/2pziz2j7781mhadl8lcfpzm8anvazb37-binutils-mesboot-2.20.1a.drv" [label = "binutils-mesboot-2.20.1a", shape = box, fontname = sans]
"/gnu/store/4ji6ayrgcyfyxpb583qr5ja4awdlxrdc-bootar-1a.drv" [label = "bootar-1a", shape = box, fontname = sans]
"/gnu/store/5x8a1yib7vdza727vrq4zmp6cmsafy7h-module-import-compiled.drv" [label = "module-import-compiled-1", shape = box, fontname = sans]
"/gnu/store/agday74gvxnd6a7191fw2g473b5v66kx-gcc-mesboot1-4.6.4.drv" [label = "gcc-mesboot1-4.6.4", shape = box, fontname = sans]
"/gnu/store/alvrmh47xqk7glq9wmvrzivfjp2bcvyc-module-import-compiled.drv" [label = "module-import-compiled-2", shape = box, fontname = sans]
"/gnu/store/asnd815v865cvfh2l2dlxmh5y556v3i5-gcc-core-mesboot0-2.95.3.drv" [label = "gcc-core-mesboot0-2.95.3", shape = box, fontname = sans]
"/gnu/store/bjhkfxc5axkjl1jv94q0lwym4n6si6f8-gcc-4.9.4.tar.xz.drv" [label = "gcc-4.9.4.tar.xz", shape = box, fontname = sans]
"/gnu/store/cf3m3ddm8dicrsxba4kjnji5lbyagvbk-gcc-mesboot0-2.95.3.drv" [label = "gcc-mesboot0-2.95.3", shape = box, fontname = sans]
"/gnu/store/d1g7i2w8k1g5jrx4n6xv4q8xnrlmz8f3-module-import-compiled.drv" [label = "module-import-compiled-3", shape = box, fontname = sans]
"/gnu/store/fdmz5blhzfczkpjb9jj6bdbhqlpv3i7l-gcc-7.5.0.drv" [label = "gcc-7.5.0", shape = box, fontname = sans]
"/gnu/store/fs2r7irjx7ppqks3zhsqmxb8lah1a4v0-glibc-mesboot0-2.2.5.drv" [label = "glibc-mesboot0-2.2.5", shape = box, fontname = sans]
"/gnu/store/i5wn3xl6p0zw1vglscgk0bs9dwc6hdh6-gcc-static-5.5.0.drv" [label = "gcc-static-5.5.0", shape = box, fontname = sans]
"/gnu/store/imx7vf2qg44yg9i4gsbn5bgpj3crcyr8-gcc-7.5.0.tar.xz.drv" [label = "gcc-7.5.0.tar.xz", shape = box, fontname = sans]
"/gnu/store/lhhbpfhk2xm8znvhnbrig8dfgd9xc80k-libstdc++-7.5.0.drv" [label = "libstdc++-7.5.0", shape = box, fontname = sans]
"/gnu/store/mrsasf73k1yvdcbn1wyb4ad6dk7ns3vn-binutils-mesboot1-2.14.drv" [label = "binutils-mesboot1-2.14", shape = box, fontname = sans]
"/gnu/store/wxpvfy5g3xjl0kp85cmmy66057p88kln-binutils-cross-boot0-2.34.drv" [label = "binutils-cross-boot0-2.34", shape = box, fontname = sans]
"/gnu/store/y4g2gsdxbk2kmp7lih88kdndi7868dnl-gash-utils-boot-0.1.0.drv" [label = "gash-utils-boot-0.1.0", shape = box, fontname = sans]
"/gnu/store/yz7h0nf33465a32yjpm9rh6w9959h34q-gcc-mesboot-4.9.4.drv" [label = "gcc-mesboot-4.9.4", shape = box, fontname = sans]
"/gnu/store/zf6himkd5rz2ll8ym0c2488bgpnkjkkr-gash-boot-0.2.0.drv" [label = "gash-boot-0.2.0", shape = box, fontname = sans]

"/gnu/store/i5wn3xl6p0zw1vglscgk0bs9dwc6hdh6-gcc-static-5.5.0.drv" -> "/gnu/store/fdmz5blhzfczkpjb9jj6bdbhqlpv3i7l-gcc-7.5.0.drv"
"/gnu/store/fdmz5blhzfczkpjb9jj6bdbhqlpv3i7l-gcc-7.5.0.drv" -> "/gnu/store/0zkiqxwm6k637xr5s1690nwllnvybvyw-xz-mesboot-5.0.0.drv"
"/gnu/store/fdmz5blhzfczkpjb9jj6bdbhqlpv3i7l-gcc-7.5.0.drv" -> "/gnu/store/d1g7i2w8k1g5jrx4n6xv4q8xnrlmz8f3-module-import-compiled.drv"
"/gnu/store/fdmz5blhzfczkpjb9jj6bdbhqlpv3i7l-gcc-7.5.0.drv" -> "/gnu/store/imx7vf2qg44yg9i4gsbn5bgpj3crcyr8-gcc-7.5.0.tar.xz.drv"
"/gnu/store/fdmz5blhzfczkpjb9jj6bdbhqlpv3i7l-gcc-7.5.0.drv" -> "/gnu/store/lhhbpfhk2xm8znvhnbrig8dfgd9xc80k-libstdc++-7.5.0.drv"
"/gnu/store/fdmz5blhzfczkpjb9jj6bdbhqlpv3i7l-gcc-7.5.0.drv" -> "/gnu/store/wxpvfy5g3xjl0kp85cmmy66057p88kln-binutils-cross-boot0-2.34.drv"
"/gnu/store/0zkiqxwm6k637xr5s1690nwllnvybvyw-xz-mesboot-5.0.0.drv" -> "/gnu/store/agday74gvxnd6a7191fw2g473b5v66kx-gcc-mesboot1-4.6.4.drv"
"/gnu/store/0zkiqxwm6k637xr5s1690nwllnvybvyw-xz-mesboot-5.0.0.drv" -> "/gnu/store/d1g7i2w8k1g5jrx4n6xv4q8xnrlmz8f3-module-import-compiled.drv"
"/gnu/store/0zkiqxwm6k637xr5s1690nwllnvybvyw-xz-mesboot-5.0.0.drv" -> "/gnu/store/fs2r7irjx7ppqks3zhsqmxb8lah1a4v0-glibc-mesboot0-2.2.5.drv"
"/gnu/store/0zkiqxwm6k637xr5s1690nwllnvybvyw-xz-mesboot-5.0.0.drv" -> "/gnu/store/mrsasf73k1yvdcbn1wyb4ad6dk7ns3vn-binutils-mesboot1-2.14.drv"
"/gnu/store/agday74gvxnd6a7191fw2g473b5v66kx-gcc-mesboot1-4.6.4.drv" -> "/gnu/store/cf3m3ddm8dicrsxba4kjnji5lbyagvbk-gcc-mesboot0-2.95.3.drv"
"/gnu/store/agday74gvxnd6a7191fw2g473b5v66kx-gcc-mesboot1-4.6.4.drv" -> "/gnu/store/d1g7i2w8k1g5jrx4n6xv4q8xnrlmz8f3-module-import-compiled.drv"

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Ludovic Courtès]

Hi Chris & all,

Apologies for taking so long to reply!  Pinging me on IRC was the right
move.  :-)

Chris Marusich  skribis:

> I'm afraid I've hit a snag using what you've uploaded, though.  It looks
> like we'll need to extract bash, mkdir, tar, and xz from
> static-binaries-0-powerpc64le-linux-gnu.tar.xz and place a copy of each
> in the following locations:
>
> - https://alpha.gnu.org/gnu/guix/bootstrap/powerpc64le-linux/20210106/bash
> - https://alpha.gnu.org/gnu/guix/bootstrap/powerpc64le-linux/20210106/mkdir
> - https://alpha.gnu.org/gnu/guix/bootstrap/powerpc64le-linux/20210106/tar
> - https://alpha.gnu.org/gnu/guix/bootstrap/powerpc64le-linux/20210106/xz
>
> Could you do that?  The reason why it's necessary is described below.

I’ve uploaded these four files now.

> I've started making changes locally to (gnu packages bootstrap).  So
> far, with the attached patch, I'm able to do the following things on my
> POWER9 machine running ppc64le Debian (unstable).
>
> I can successfully build Guix from source using Debian packages (and a
> manually-built copy of guile-avahi and guile-gnutls).  With my patch, I
> still have to supply the "--with-courage" configure option.  Although
> "make" succeeded, "make check" failed on the following tests:
>
> - tests/build-utils.scm
> - test/challenge.scm
> - tests/containers.scm
> - tests/debug-link.scm
>
> The failures fell into two categories:
>
> - Some tests couldn't download the bootstrap bash.
> - In tests/containers.scm, call-with-container evaluated to #f when it
>   wasn't supposed to.

Perhaps we can investigate them later.

> Nevertheless, I created the necessary build users and started the
> guix-daemon via pre-inst-env.  I then tried building a simple package:
>
>   ./pre-inst-env guix build -e '(@@ (gnu packages bootstrap) 
> %bootstrap-coreutils)'

[...]

> Starting download of 
> /gnu/store/2phdifnfw6i989rqbav04zakxx7qb165-static-binaries-0-powerpc64le-linux-gnu.tar.xz
> From 
> https://ftp.gnu.org/gnu/guix/bootstrap/powerpc64le-linux/20210106/static-binaries-0-powerpc64le-linux-gnu.tar.xz...

> failed to download "/gnu/store/0kaj6l1ccw0qd0289hii7qhr828s71sv-bash" from 
> ("https://git.savannah.gnu.org/cgit/guix.git/plain/gnu/packages/bootstrap/powerpc64le-linux/20210106/bash;
>  "http://lilypond.org/janneke/guix/powerpc64le-linux/20210106/bash;)
> builder for `/gnu/store/ix4mpvzxfi1hrmvdmmpgqhm9x1cdh347-bash.drv' failed to 
> produce output path `/gnu/store/0kaj6l1ccw0qd0289hii7qhr828s71sv-bash'

Note that for testing purposes, you could always work around this by
adding these four files to the store with the ‘add-to-store’ RPC (I
don’t think ‘guix download’ would work because you need the executable
bit.)

> By the way, I've noticed that the other architectures don't seem to have
> "raw" binaries at all on alpha.gnu.org.  Maybe you already knew this,
> but it seems that the "raw" binaries are actually downloaded from this
> specific URL (see the bootstrap-executable-file-name procedure):
>
> https://git.savannah.gnu.org/cgit/guix.git/plain/gnu/packages/bootstrap/?id=44f07d1dc6806e97c4e9ee3e6be883cc59dc666e
>
> Is that intended?

Yes: these files used to be in version control, part of the Guix source
tarball, but now we just download them (commit
836a85da0e8609d40716581be00802ee43463038).

> I was surprised to discover that we store these four "raw" binaries in
> a totally separate place.  That seems like it would make it easy for
> someone to accidentally forget to update the "raw" binaries when they
> update an architecture's bootstrap tarballs.

They’re visible in the dependency graph though, and they don’t need to
ever change.

Ludo’.

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Chris Marusich]

Hi Ludo,

I hope you're doing well!  If you can find the time to upload those
"raw" binaries, too, we can continue trying to bootstrap.  For details,
please refer to my last message, here:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41669#128

Thank you for your help!

-- 
Chris


signature.asc
Description: PGP signature

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Chris Marusich]

Hi Ludo,

Ludovic Courtès  writes:

> You can update (gnu packages bootstrap) accordingly.

Thank you for uploading the little-endian bootstrap binaries!  I've
downloaded them, and I confirm that they are identical to the ones I
built.  Do you also plan to upload the big-endian bootstrap binaries?  I
think we were hoping to try both system types.

I'm afraid I've hit a snag using what you've uploaded, though.  It looks
like we'll need to extract bash, mkdir, tar, and xz from
static-binaries-0-powerpc64le-linux-gnu.tar.xz and place a copy of each
in the following locations:

- https://alpha.gnu.org/gnu/guix/bootstrap/powerpc64le-linux/20210106/bash
- https://alpha.gnu.org/gnu/guix/bootstrap/powerpc64le-linux/20210106/mkdir
- https://alpha.gnu.org/gnu/guix/bootstrap/powerpc64le-linux/20210106/tar
- https://alpha.gnu.org/gnu/guix/bootstrap/powerpc64le-linux/20210106/xz

Could you do that?  The reason why it's necessary is described below.

I've started making changes locally to (gnu packages bootstrap).  So
far, with the attached patch, I'm able to do the following things on my
POWER9 machine running ppc64le Debian (unstable).

I can successfully build Guix from source using Debian packages (and a
manually-built copy of guile-avahi and guile-gnutls).  With my patch, I
still have to supply the "--with-courage" configure option.  Although
"make" succeeded, "make check" failed on the following tests:

- tests/build-utils.scm
- test/challenge.scm
- tests/containers.scm
- tests/debug-link.scm

The failures fell into two categories:

- Some tests couldn't download the bootstrap bash.
- In tests/containers.scm, call-with-container evaluated to #f when it
  wasn't supposed to.

Nevertheless, I created the necessary build users and started the
guix-daemon via pre-inst-env.  I then tried building a simple package:

  ./pre-inst-env guix build -e '(@@ (gnu packages bootstrap) 
%bootstrap-coreutils)'

The result was promising, but it quickly failed like some of the tests
did - it couldn't download the bash bootstrap binary:

--8<---cut here---start->8---
marusich@suzaku:~/repos/guix$ ./pre-inst-env guix build -e '(@@ (gnu packages 
bootstrap) %bootstrap-coreutils)'
substitute: guix substitute: warning: ACL for archive imports seems to be 
uninitialized, substitutes may be unavailable
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
The following derivations will be built:
   /gnu/store/y9868ab6a4wjcvwzj4ln5fzk1y4y6zpz-bootstrap-binaries-0.drv
   /gnu/store/2nwml4l272qzq034hwf5icv9vxi813ja-xz.drv
   /gnu/store/c1v9lmsh0awbhpai72mzw4qv02rrbpw6-module-import-compiled.drv
   /gnu/store/n5hf44bybvqmsybjvnn61pkpmcdcrlbd-guile-bootstrap-2.0.drv
   /gnu/store/ix4mpvzxfi1hrmvdmmpgqhm9x1cdh347-bash.drv
   /gnu/store/jxh9xn77flxarwzcjga485pgrkjknrgb-tar.drv
   
/gnu/store/yd1mib8s1f38qwdn61zj16ijx8p0ryzm-guile-static-stripped-2.0.14-powerpc64le-linux-gnu.tar.xz.drv
   /gnu/store/z66wc9z4qvffn60q4jdx7in6rxpswhx3-mkdir.drv
   
/gnu/store/m4qv668s851v2ndzns3xwzg5rga9fhff-static-binaries-0-powerpc64le-linux-gnu.tar.xz.drv
building 
/gnu/store/m4qv668s851v2ndzns3xwzg5rga9fhff-static-binaries-0-powerpc64le-linux-gnu.tar.xz.drv...

Starting download of 
/gnu/store/2phdifnfw6i989rqbav04zakxx7qb165-static-binaries-0-powerpc64le-linux-gnu.tar.xz
From 
https://ftp.gnu.org/gnu/guix/bootstrap/powerpc64le-linux/20210106/static-binaries-0-powerpc64le-linux-gnu.tar.xz...
download failed 
"https://ftp.gnu.org/gnu/guix/bootstrap/powerpc64le-linux/20210106/static-binaries-0-powerpc64le-linux-gnu.tar.xz;
 404 "Not Found"

Starting download of 
/gnu/store/2phdifnfw6i989rqbav04zakxx7qb165-static-binaries-0-powerpc64le-linux-gnu.tar.xz
From 
https://alpha.gnu.org/gnu/guix/bootstrap/powerpc64le-linux/20210106/static-binaries-0-powerpc64le-linux-gnu.tar.xz...
downloading from 
https://alpha.gnu.org/gnu/guix/bootstrap/powerpc64le-linux/20210106/static-binaries-0-powerpc64le-linux-gnu.tar.xz
 ...
 static-binaries-0-powerpc64le-linux-gnu.tar.xz  4.4MiB 2.8MiB/s 00:02 
[##] 100.0%
successfully built 
/gnu/store/m4qv668s851v2ndzns3xwzg5rga9fhff-static-binaries-0-powerpc64le-linux-gnu.tar.xz.drv
building /gnu/store/ix4mpvzxfi1hrmvdmmpgqhm9x1cdh347-bash.drv...

Starting download of /gnu/store/0kaj6l1ccw0qd0289hii7qhr828s71sv-bash
From 
https://git.savannah.gnu.org/cgit/guix.git/plain/gnu/packages/bootstrap/powerpc64le-linux/20210106/bash...
download failed 
"https://git.savannah.gnu.org/cgit/guix.git/plain/gnu/packages/bootstrap/powerpc64le-linux/20210106/bash;
 404 "Not found"

Starting download of /gnu/store/0kaj6l1ccw0qd0289hii7qhr828s71sv-bash
From http://lilypond.org/janneke/guix/powerpc64le-linux/20210106/bash...
download failed 
"http://lilypond.org/janneke/guix/powerpc64le-linux/20210106/bash; 404 "Not 
Found"

Starting download of /gnu/store/0kaj6l1ccw0qd0289hii7qhr828s71sv-bash
From 

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Ludovic Courtès]

Hi Chris,

Chris Marusich  skribis:

> No, we need a separate tarball for LE.  I have prepared that here:
>
> https://media.marusich.info/guix-ppc64le-bootstrap/powerpc64le-linux-gnu-bootstrap-tarballs-from-guix-662e7e28d576.tar.xz
> https://media.marusich.info/guix-ppc64le-bootstrap/powerpc64le-linux-gnu-bootstrap-tarballs-from-guix-662e7e28d576.tar.xz.sha512sum
> https://media.marusich.info/guix-ppc64le-bootstrap/powerpc64le-linux-gnu-bootstrap-tarballs-from-guix-662e7e28d576.tar.xz.asc

Thanks.  I have uploaded them to

(I meant to send them to ftp.gnu.org but typed it wrong; I can upload
them there as well later.)

You can update (gnu packages bootstrap) accordingly.

> This tarball, containing the little-endian bootstrap binaries, was
> generated using the same setup that I used earlier for big-endian.
> Specifically, to generate the little-endian bootstrap binaries, I took
> the following steps on two separate VMs:
>
> - Use
>   https://ftp.gnu.org/gnu/guix/guix-system-install-1.2.0.x86_64-linux.iso.xz
>   to install Guix System 1.2.0 on an x86_64-linux machine.
> - Run: guix pull --no-substitutes 
> --commit=1ced8379c7641788fa607b19b7a66d18f045362b
> - Run: guix pull --no-substitutes 
> --commit=662e7e28d576ada91fc9dec7d27c100666114f03
> - Run: guix build --no-substitutes --target=powerpc64le-linux-gnu 
> bootstrap-tarballs
> - I didn't run "guix system reconfigure" after installing Guix System;
>   theoretically it shouldn't matter, but for the purpose of our
>   experiment, I just left the system in its default configuration in
>   order to ensure that the kernel etc. would be the same on both VMs.

In the commit log that updates (gnu packages bootstrap), please mention
these commands so we later know how those binaries were obtained.  (Only
the second ‘guix pull’ matters.)

> By the way, just as with the big endian bootstrap binaries, all the
> little endian bootstrap binaries I built were identical on both VMs
> except for gcc-static.  The output of gcc-static contained binaries that
> differed in ways similar to what has been described earlier in this
> thread.  So, the non-reproducibility of gcc-static is not specific to
> one PPC architecture.  I wonder if gcc-static can be cross-built
> reproducibly for any architecture at all.

Yeah, that remains a mystery, perhaps we’ll eventually find out!

>> (As you know, we use i386 binaries for both i686-linux and x86_64-linux.
>> Likewise, if we can have a single set of binaries instead of having
>> PPC32, PPC64, and PPC64LE, that’s better.)
>
> This is a fair question.  I agree that if it were possible, it would be
> a great improvement.  I didn't know the answer to this question, so I
> asked in #talos-workstation on Freenode.  The users there said that
> although in theory this should be possible, it isn't currently feasible
> because the ability to do this is not currently implemented in Linux.
>
> For the moment, I think our focus should be on finding out which of
> these two architectures can be bootstrapped in Guix in the first place.
> The first step in doing that is to try using these bootstrap binaries.

Yes, that makes sense to me.

Thank you!

Ludo’.


signature.asc
Description: PGP signature

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Chris Marusich]

Chris Marusich  writes:

> If it's just for the sake of trying one last time, we could just add
> --cores=1 to the Guix invocations, or run everything in a single-core
> VM.  Wouldn't that have the same effect?
>
> I think you'll probably agree, so I've proactively started another build
> on two fresh single-core VMs (using the same procedure I described
> earlier, starting from the 1.2.0 installation ISO image).  It'll take a
> few days to finish, I'm sure.  Please let me know if you think we need
> the patch to run this final experiment.  Otherwise, I'll just report the
> results of this latest experiment in a few days' time.

The builds finished on both of my VMs (new ones) the other day. The
result was the same as before: Even when built from source using a
single core and with --cores=1, gcc-static differed, and all other
binaries were identical.  This is more evidence to support the
conclusion that the non-reproducibility is not due to concurrency.

For the record, this is the summary of the final experiment I did:

- I created two new x86_64 VMs using QEMU.
- I used
  https://ftp.gnu.org/gnu/guix/guix-system-install-1.2.0.x86_64-linux.iso.xz
  to install Guix System 1.2.0 on these two VMs.
- I ran: guix pull --cores=1 --no-substitutes 
--commit=1ced8379c7641788fa607b19b7a66d18f045362b
- I ran: guix build --cores=1 --no-substitutes --target=powerpc64-linux-gnu 
bootstrap-tarballs
- I didn't run "guix system reconfigure" after installing Guix System;
  theoretically it shouldn't matter, but for the purpose of our
  experiment, I just left the system in its default configuration in
  order to ensure that the kernel etc. would be the same on both VMs.

In reality, it didn't go so smoothly.  While running "guix pull", the
build for guile failed many times before I got it to succeed, which
prompted me to submit this bug report:

"Guile 3 fails to build non-deterministically"
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45574

While running "guix pull", the build for gnutls failed many times and
never succeeded - so I actually did substitute gnutls.  I submitted a
bug report for that one here, too:

"gnutls 3.6.12 can consistently fail to build"
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45578

In any case, this confirms Leo's findings.  It's clear that concurrency
is not the reason why gcc-static builds non-reproducibly.

-- 
Chris


signature.asc
Description: PGP signature

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Chris Marusich]

Hi Ludo,

Ludovic Courtès  writes:

>>> https://media.marusich.info/guix-ppc64-bootstrap/bootstrap-tarballs-from-guix-1ced8379c7.tar.xz
>>> https://media.marusich.info/guix-ppc64-bootstrap/bootstrap-tarballs-from-guix-1ced8379c7.tar.xz.asc
>>> https://media.marusich.info/guix-ppc64-bootstrap/bootstrap-tarballs-from-guix-1ced8379c7.tar.xz.sha512sum
>
> [...]
>
> IIUC, the tarballs at the URL above are for PPC64 (system type:
> ‘powerpc64-linux’); is this also going to work on PPC64LE hardware?

No, we need a separate tarball for LE.  I have prepared that here:

https://media.marusich.info/guix-ppc64le-bootstrap/powerpc64le-linux-gnu-bootstrap-tarballs-from-guix-662e7e28d576.tar.xz
https://media.marusich.info/guix-ppc64le-bootstrap/powerpc64le-linux-gnu-bootstrap-tarballs-from-guix-662e7e28d576.tar.xz.sha512sum
https://media.marusich.info/guix-ppc64le-bootstrap/powerpc64le-linux-gnu-bootstrap-tarballs-from-guix-662e7e28d576.tar.xz.asc

This tarball, containing the little-endian bootstrap binaries, was
generated using the same setup that I used earlier for big-endian.
Specifically, to generate the little-endian bootstrap binaries, I took
the following steps on two separate VMs:

- Use
  https://ftp.gnu.org/gnu/guix/guix-system-install-1.2.0.x86_64-linux.iso.xz
  to install Guix System 1.2.0 on an x86_64-linux machine.
- Run: guix pull --no-substitutes 
--commit=1ced8379c7641788fa607b19b7a66d18f045362b
- Run: guix pull --no-substitutes 
--commit=662e7e28d576ada91fc9dec7d27c100666114f03
- Run: guix build --no-substitutes --target=powerpc64le-linux-gnu 
bootstrap-tarballs
- I didn't run "guix system reconfigure" after installing Guix System;
  theoretically it shouldn't matter, but for the purpose of our
  experiment, I just left the system in its default configuration in
  order to ensure that the kernel etc. would be the same on both VMs.

Notice that there are two "guix pull" invocations.  This is because I
first pulled to 1ced8379c7641788fa607b19b7a66d18f045362b in order to
build the big-endian bootstrap-tarballs as described earlier.  After
that, I pulled to 662e7e28d576ada91fc9dec7d27c100666114f03 in order to
build the little-endian bootstrap-tarballs on the same machine.  In
theory it shouldn't matter how you arrive at commit
662e7e28d576ada91fc9dec7d27c100666114f03, but for the sake of
completeness and reproducibility I've included both pull steps.

By the way, just as with the big endian bootstrap binaries, all the
little endian bootstrap binaries I built were identical on both VMs
except for gcc-static.  The output of gcc-static contained binaries that
differed in ways similar to what has been described earlier in this
thread.  So, the non-reproducibility of gcc-static is not specific to
one PPC architecture.  I wonder if gcc-static can be cross-built
reproducibly for any architecture at all.

> (As you know, we use i386 binaries for both i686-linux and x86_64-linux.
> Likewise, if we can have a single set of binaries instead of having
> PPC32, PPC64, and PPC64LE, that’s better.)

This is a fair question.  I agree that if it were possible, it would be
a great improvement.  I didn't know the answer to this question, so I
asked in #talos-workstation on Freenode.  The users there said that
although in theory this should be possible, it isn't currently feasible
because the ability to do this is not currently implemented in Linux.

For the moment, I think our focus should be on finding out which of
these two architectures can be bootstrapped in Guix in the first place.
The first step in doing that is to try using these bootstrap binaries.

-- 
Chris


signature.asc
Description: PGP signature

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Efraim Flashner]

On Mon, Jan 04, 2021 at 10:37:20AM +0100, Ludovic Courtès wrote:
> Hi,
> 
> Leo Le Bouter  skribis:
> 
> > On Sat, 2020-12-19 at 23:28 -0800, Chris Marusich wrote:
> >> Now that we have decided to use these powerpc64 bootstrap tarballs,
> >> what
> >> are the next steps for uploading them to the GNU FTP server?  I've
> >> never
> >> done that before, and I don't think I have access.  For now I've put
> >> a
> >> signed copy of the powerpc64-linux (big endian) bootstrap tarballs,
> >> with
> >> a SHA-512 hash, here:
> >> 
> >> https://media.marusich.info/guix-ppc64-bootstrap/bootstrap-tarballs-from-guix-1ced8379c7.tar.xz
> >> https://media.marusich.info/guix-ppc64-bootstrap/bootstrap-tarballs-from-guix-1ced8379c7.tar.xz.asc
> >> https://media.marusich.info/guix-ppc64-bootstrap/bootstrap-tarballs-from-guix-1ced8379c7.tar.xz.sha512sum
> 
> [...]
> 
> > Can you do it? Upload the binaries on GNU FTP server? Little endian
> > binaries will come along shortly as well.
> 
> Sure.  IIUC, the tarballs at the URL above are for PPC64 (system type:
> ‘powerpc64-linux’); is this also going to work on PPC64LE hardware?
> 
> (As you know, we use i386 binaries for both i686-linux and x86_64-linux.
> Likewise, if we can have a single set of binaries instead of having
> PPC32, PPC64, and PPC64LE, that’s better.)

Last I checked the PPC32 binaries aren't working. Even cbmuser from
Debian thinks there may be a glibc bug with glibc-2.32 so I can't test
that much ATM¹.

Rather than effectively needing to wait to add ppc32 and ppc64 at the
same time it'd be better to add them individually and then do any
rebasing necessary to make them both work with ppc32 binaries later.

¹ If my patch fixes it I'll add glibc hacker to my résumé.

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


signature.asc
Description: PGP signature

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Ludovic Courtès]

Hi,

Leo Le Bouter  skribis:

> On Sat, 2020-12-19 at 23:28 -0800, Chris Marusich wrote:
>> Now that we have decided to use these powerpc64 bootstrap tarballs,
>> what
>> are the next steps for uploading them to the GNU FTP server?  I've
>> never
>> done that before, and I don't think I have access.  For now I've put
>> a
>> signed copy of the powerpc64-linux (big endian) bootstrap tarballs,
>> with
>> a SHA-512 hash, here:
>> 
>> https://media.marusich.info/guix-ppc64-bootstrap/bootstrap-tarballs-from-guix-1ced8379c7.tar.xz
>> https://media.marusich.info/guix-ppc64-bootstrap/bootstrap-tarballs-from-guix-1ced8379c7.tar.xz.asc
>> https://media.marusich.info/guix-ppc64-bootstrap/bootstrap-tarballs-from-guix-1ced8379c7.tar.xz.sha512sum

[...]

> Can you do it? Upload the binaries on GNU FTP server? Little endian
> binaries will come along shortly as well.

Sure.  IIUC, the tarballs at the URL above are for PPC64 (system type:
‘powerpc64-linux’); is this also going to work on PPC64LE hardware?

(As you know, we use i386 binaries for both i686-linux and x86_64-linux.
Likewise, if we can have a single set of binaries instead of having
PPC32, PPC64, and PPC64LE, that’s better.)

Thanks,
Ludo’.

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Leo Le Bouter via Bug reports for GNU Guix]

Hello Ludo!

On Sat, 2020-12-19 at 23:28 -0800, Chris Marusich wrote:
> Now that we have decided to use these powerpc64 bootstrap tarballs,
> what
> are the next steps for uploading them to the GNU FTP server?  I've
> never
> done that before, and I don't think I have access.  For now I've put
> a
> signed copy of the powerpc64-linux (big endian) bootstrap tarballs,
> with
> a SHA-512 hash, here:
> 
> https://media.marusich.info/guix-ppc64-bootstrap/bootstrap-tarballs-from-guix-1ced8379c7.tar.xz
> https://media.marusich.info/guix-ppc64-bootstrap/bootstrap-tarballs-from-guix-1ced8379c7.tar.xz.asc
> https://media.marusich.info/guix-ppc64-bootstrap/bootstrap-tarballs-from-guix-1ced8379c7.tar.xz.sha512sum
> 
> For the record, these bootstrap tarballs were built via the following
> steps:
> 
> - Use
>   
> https://ftp.gnu.org/gnu/guix/guix-system-install-1.2.0.x86_64-linux.iso.xz
>   to install Guix System 1.2.0 on an x86_64-linux machine.
> - Run: guix pull --no-substitutes --
> commit=1ced8379c7641788fa607b19b7a66d18f045362b
> - Run: guix build --no-substitutes --target=powerpc64-linux-gnu
> bootstrap-tarballs
> - I didn't run "guix system reconfigure" after installing Guix
> System;
>   theoretically it shouldn't matter, but for the purpose of our
>   experiment, I just left the system in its default configuration in
>   order to ensure that the kernel etc. would be the same on both VMs.
> 
> Once we get these binaries into the GNU FTP server, 

Can you do it? Upload the binaries on GNU FTP server? Little endian
binaries will come along shortly as well. We decided (Chris and me)
that obsessing on this problem any longer is not going to help us
complete this port, the amount of struggle is getting very
demotivating. We got reasonable proof that this non-reproducibility GCC
problem exists and is non-trivial to solve, that's what I wanted with
the last attempts, I had hope it could still be trivial but turns out
not.

> I'll get started on
> updating gnu/packages/bootstrap.scm and other files necessary to
> begin
> bootstrapping powerpc64-linux.  I'll mainly be adapting the work that
> Leo already did, and following the lead of others like Efraim and his
> work on the wip-ppc branch.  I will probably have questions as I go,
> so
> I'll ask on guix-devel.
> 
> Please let me know if you'd like this done on a special branch.
> 

Thank you


signature.asc
Description: This is a digitally signed message part

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Efraim Flashner]

On Mon, Dec 28, 2020 at 09:59:26PM +0100, Leo Le Bouter wrote:
> On Mon, 2020-12-28 at 20:01 +0100, Leo Le Bouter wrote:
> > By the way here's my powerpc64le-linux-gnu hash:
> > 
> > $ sha256sum /gnu/store/cc4sj9kiw1vzhhhxawnqvjjdi4ygbxp5-gcc-stripped-
> > tarball-5.5.0/gcc-stripped-5.5.0-powerpc64le-linux-gnu.tar.xz
> > 153f356a8f58102e7e57a006e836ec7450e69dee120ba83d9f7dacf07162537b  /gn
> > u/store/cc4sj9kiw1vzhhhxawnqvjjdi4ygbxp5-gcc-stripped-tarball-
> > 5.5.0/gcc-stripped-5.5.0-powerpc64le-linux-gnu.tar.xz
> 
> Nevermind, tried in a brand new single-core VM on my laptop and it did
> not reproduce...

ab2fd297f65df5ab6fb5662dc3988f8421f2194026ac3df97eba3b53832796b9  
/gnu/store/cc4sj9kiw1vzhhhxawnqvjjdi4ygbxp5-gcc-stripped-tarball-5.5.0/gcc-stripped-5.5.0-powerpc64le-linux-gnu.tar.xz
9bf3685309b68cc0a39b2dc783ada393e6ef889398dd21fd07c7893159c13cc0  
/gnu/store/kjxwb8lwbgnp2np7ji8dvjmh290p1jnm-gcc-stripped-tarball-5.5.0/gcc-stripped-5.5.0-powerpc64-linux-gnu.tar.xz

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


signature.asc
Description: PGP signature

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Leo Le Bouter via Bug reports for GNU Guix]

On Mon, 2020-12-28 at 20:01 +0100, Leo Le Bouter wrote:
> By the way here's my powerpc64le-linux-gnu hash:
> 
> $ sha256sum /gnu/store/cc4sj9kiw1vzhhhxawnqvjjdi4ygbxp5-gcc-stripped-
> tarball-5.5.0/gcc-stripped-5.5.0-powerpc64le-linux-gnu.tar.xz
> 153f356a8f58102e7e57a006e836ec7450e69dee120ba83d9f7dacf07162537b  /gn
> u/store/cc4sj9kiw1vzhhhxawnqvjjdi4ygbxp5-gcc-stripped-tarball-
> 5.5.0/gcc-stripped-5.5.0-powerpc64le-linux-gnu.tar.xz

Nevermind, tried in a brand new single-core VM on my laptop and it did
not reproduce...


signature.asc
Description: This is a digitally signed message part

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Leo Le Bouter via Bug reports for GNU Guix]

By the way here's my powerpc64le-linux-gnu hash:

$ sha256sum 
/gnu/store/cc4sj9kiw1vzhhhxawnqvjjdi4ygbxp5-gcc-stripped-tarball-5.5.0/gcc-stripped-5.5.0-powerpc64le-linux-gnu.tar.xz
153f356a8f58102e7e57a006e836ec7450e69dee120ba83d9f7dacf07162537b  
/gnu/store/cc4sj9kiw1vzhhhxawnqvjjdi4ygbxp5-gcc-stripped-tarball-5.5.0/gcc-stripped-5.5.0-powerpc64le-linux-gnu.tar.xz


signature.asc
Description: This is a digitally signed message part

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Leo Le Bouter via Bug reports for GNU Guix]

On Mon, 2020-12-28 at 16:31 +0100, Leo Le Bouter wrote:
> I modified my virtual machine to only have a single core because it
> seems --cores=1 does not work properly with cross-compilation.

Great news! I think using only 1 core fixes it. But since --cores=1 is
broken for cross-compilation it seems, I had to use a single-core VM.

Can you do the same? (Create a single-core x86_64 however you want VM,
run a command and report hashes)

$ guix gc && sha256sum "$(guix build -M 1 -c 1 --target=powerpc64le-linux-gnu 
-e '(@@ (gnu packages make-bootstrap) 
%gcc-bootstrap-tarball)')/gcc-stripped-5.5.0-powerpc64le-linux-gnu.tar.xz"

Also try with powerpc64-linux-gnu:

$ guix gc && sha256sum "$(guix build -M 1 -c 1 --target=powerpc64-linux-gnu -e 
'(@@ (gnu packages make-bootstrap) 
%gcc-bootstrap-tarball)')/gcc-stripped-5.5.0-powerpc64-linux-gnu.tar.xz"

Thanks a lot!



signature.asc
Description: This is a digitally signed message part

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Leo Le Bouter via Bug reports for GNU Guix]

On Mon, 2020-12-28 at 13:55 +0100, Leo Le Bouter wrote:
> I did the same, I ran on both my laptop and another VM in the server:
> 
> $ ./pre-inst-env guix build --no-offload --cores=1 --
> target=powerpc64le-linux-gnu -e '(@@ (gnu packages make-bootstrap)
> %gcc-static)'
> 
> With latest master.
> 
> Let's see!

I modified my virtual machine to only have a single core because it
seems --cores=1 does not work properly with cross-compilation.


signature.asc
Description: This is a digitally signed message part

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Leo Le Bouter via Bug reports for GNU Guix]

On Sun, 2020-12-27 at 20:23 -0800, Chris Marusich wrote:
> I think you'll probably agree, so I've proactively started another
> build
> on two fresh single-core VMs (using the same procedure I described
> earlier, starting from the 1.2.0 installation ISO image).  It'll take
> a
> few days to finish, I'm sure.  Please let me know if you think we
> need
> the patch to run this final experiment.  Otherwise, I'll just report
> the
> results of this latest experiment in a few days' time.
> 

I did the same, I ran on both my laptop and another VM in the server:

$ ./pre-inst-env guix build --no-offload --cores=1 --
target=powerpc64le-linux-gnu -e '(@@ (gnu packages make-bootstrap)
%gcc-static)'

With latest master.

Let's see!


signature.asc
Description: This is a digitally signed message part

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Leo Le Bouter via Bug reports for GNU Guix]

On Sun, 2020-12-27 at 20:23 -0800, Chris Marusich wrote:
> If it's just for the sake of trying one last time, we could just add
> --cores=1 to the Guix invocations, or run everything in a single-core
> VM.  Wouldn't that have the same effect?

My system has an offload set up and somehow --cores=1 does not work, so
I needed this patch to make sure, also to optimize run-time I tried to
disable parallel build only for gcc.

I also tried to build only the gcc-static binary with:

$ ./pre-inst-env guix build --cores=1 --target=powerpc64le-linux-gnu -e
'(@@ (gnu packages make-bootstrap) %gcc-static)'


signature.asc
Description: This is a digitally signed message part

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Efraim Flashner]

On Mon, Dec 28, 2020 at 03:25:27AM +0100, Leo Le Bouter wrote:
> Hello!
> 
> I want to have one last attempt at making the binaries reproducible.
> 
> Could anyone help adjusting this patch so the package definition's hash
> does not change on other architectures? So it can be proposed for merge
> in master..
> 
> Thank you

I think you'll find the proposed patch does exactly the opposite of what
you want :P





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


signature.asc
Description: PGP signature

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Efraim Flashner]

On Sun, Dec 27, 2020 at 08:23:21PM -0800, Chris Marusich wrote:
> Leo Le Bouter  writes:
> 
> > I want to have one last attempt at making the binaries reproducible.
> >
> > Could anyone help adjusting this patch so the package definition's hash
> > does not change on other architectures? So it can be proposed for merge
> > in master..
> >
> > Thank you
> >
> > From e6931a7ebb9cc0681a3211ac38a1c58c7a176481 Mon Sep 17 00:00:00 2001
> > From: John Doe 
> > Date: Mon, 28 Dec 2020 03:21:08 +0100
> > Subject: [PATCH] gnu: gcc-4.7: Disable parallel compilation on powerpc64*.
> >
> > * gnu/packages/gcc.scm (gcc-4.7)[arguments]: Conditionally disable
> >   parallel compilation on powerpc64*.
> > ---
> >  gnu/packages/gcc.scm | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm
> > index 4d5aaa7070..6d32677144 100644
> > --- a/gnu/packages/gcc.scm
> > +++ b/gnu/packages/gcc.scm
> > @@ -204,6 +204,8 @@ where the OS part is overloaded to denote a specific 
> > ABI---into GCC
> >  ,(if stripped? "-g0" "-g")
> >  
> >#:tests? #f
> > +  #:parallel-build? ,(string-prefix? "powerpc64" (or 
> > (%current-target-system)
> > +  
> > (%current-system)))
> >  
> >#:phases
> >(modify-phases %standard-phases
> 
> If it's just for the sake of trying one last time, we could just add
> --cores=1 to the Guix invocations, or run everything in a single-core
> VM.  Wouldn't that have the same effect?

Close enough. We can also add it into the commit message, to build it
with --cores=1

> I think you'll probably agree, so I've proactively started another build
> on two fresh single-core VMs (using the same procedure I described
> earlier, starting from the 1.2.0 installation ISO image).  It'll take a
> few days to finish, I'm sure.  Please let me know if you think we need
> the patch to run this final experiment.  Otherwise, I'll just report the
> results of this latest experiment in a few days' time.
> 
> -- 
> Chris



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


signature.asc
Description: PGP signature

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Chris Marusich]

Leo Le Bouter  writes:

> I want to have one last attempt at making the binaries reproducible.
>
> Could anyone help adjusting this patch so the package definition's hash
> does not change on other architectures? So it can be proposed for merge
> in master..
>
> Thank you
>
> From e6931a7ebb9cc0681a3211ac38a1c58c7a176481 Mon Sep 17 00:00:00 2001
> From: John Doe 
> Date: Mon, 28 Dec 2020 03:21:08 +0100
> Subject: [PATCH] gnu: gcc-4.7: Disable parallel compilation on powerpc64*.
>
> * gnu/packages/gcc.scm (gcc-4.7)[arguments]: Conditionally disable
>   parallel compilation on powerpc64*.
> ---
>  gnu/packages/gcc.scm | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm
> index 4d5aaa7070..6d32677144 100644
> --- a/gnu/packages/gcc.scm
> +++ b/gnu/packages/gcc.scm
> @@ -204,6 +204,8 @@ where the OS part is overloaded to denote a specific 
> ABI---into GCC
>  ,(if stripped? "-g0" "-g")
>  
>#:tests? #f
> +  #:parallel-build? ,(string-prefix? "powerpc64" (or 
> (%current-target-system)
> +  
> (%current-system)))
>  
>#:phases
>(modify-phases %standard-phases

If it's just for the sake of trying one last time, we could just add
--cores=1 to the Guix invocations, or run everything in a single-core
VM.  Wouldn't that have the same effect?

I think you'll probably agree, so I've proactively started another build
on two fresh single-core VMs (using the same procedure I described
earlier, starting from the 1.2.0 installation ISO image).  It'll take a
few days to finish, I'm sure.  Please let me know if you think we need
the patch to run this final experiment.  Otherwise, I'll just report the
results of this latest experiment in a few days' time.

-- 
Chris


signature.asc
Description: PGP signature

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Leo Le Bouter via Bug reports for GNU Guix]

Hello!

I want to have one last attempt at making the binaries reproducible.

Could anyone help adjusting this patch so the package definition's hash
does not change on other architectures? So it can be proposed for merge
in master..

Thank you
From e6931a7ebb9cc0681a3211ac38a1c58c7a176481 Mon Sep 17 00:00:00 2001
From: John Doe 
Date: Mon, 28 Dec 2020 03:21:08 +0100
Subject: [PATCH] gnu: gcc-4.7: Disable parallel compilation on powerpc64*.

* gnu/packages/gcc.scm (gcc-4.7)[arguments]: Conditionally disable
  parallel compilation on powerpc64*.
---
 gnu/packages/gcc.scm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm
index 4d5aaa7070..6d32677144 100644
--- a/gnu/packages/gcc.scm
+++ b/gnu/packages/gcc.scm
@@ -204,6 +204,8 @@ where the OS part is overloaded to denote a specific ABI---into GCC
 ,(if stripped? "-g0" "-g")
 
   #:tests? #f
+  #:parallel-build? ,(string-prefix? "powerpc64" (or (%current-target-system)
+  (%current-system)))
 
   #:phases
   (modify-phases %standard-phases
-- 
2.29.2



signature.asc
Description: This is a digitally signed message part

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Chris Marusich]

Hi all,

It's great to see forward motion again!

Efraim Flashner  writes:

> As far as powerpc64 vs powerpc64le, I'll let those with the hardware
> have more of a say, they'll be the ones using it. As far as the
> bootstrap binaries go, I don't remember having this much pushback with
> my binaries for aarch64 (just a request to rebuild with guile-2.0.14
> since it was reproducible), and I'm not sure how much Janneke had with
> the Hurd binaries but I don't think it was this much. The ultimate goal
> anyway is to replace them with artisanally crafted mes binaries, and I
> understand we want to have them as reproducible as possible, but I don't
> think it's fair to keep this architecture out when we've let other ones
> in with similar reproducible problems.

Ludovic Courtès  writes:

> 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.

I'm glad you agree.  For powerpc64 (big-endian), should we just make the
changes for bootstrapping on the master branch, or should we use a
separate branch?

If we use a separate branch, we could use the name "wip-ppc64", since
there is already a "wip-ppc64le" for powerpc64le.  Is it expected that
commits on these "wip" branches will never be modified (e.g., via
rebasing)?

Leo Le Bouter  writes:

>> Do you have a preference big-endian vs little endian?
>
> I'd like both but little endian has the widest eco-system support
> especially w.r.t. to Linux drivers. Many Linux drivers have endianness
> bugs (lack of endian-safe serialization for DMA..), it's such a plague
> that sticking to little endian is just better right now. One common
> example being mpt3sas and amdgpu drivers required in some
> configurations of the Talos II system.

Ludovic Courtès  writes:

>> 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?

I agree.  It's probably better to focus on little-endian.  However, it
isn't clear yet which will be ultimately harder for us to bootstrap, so
I also think it's fine to work on both in parallel and see how it goes.

Ludovic Courtès  writes:

> 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.

Over the last few days, Leo and I coordinated to try cross-compiling the
powerpc64 bootstrap tarballs one more time, using two Guix System VMs.
We did this because we thought that maybe if we took care to keep the
Guix Systems "the same" (e.g., same kernel), it would produce identical
results.  Instead, the result was the same as before: all bootstrap
tarballs except for gcc-static were identical, and gcc-static differed
in ways similar to what has already been described earlier in this bug
report.  In fact, with the exception of gcc-static, the bootstrap
tarballs were identical to the tarballs multiple people built 6 months
ago in June.  This means that (1) with the exception of gcc-static, the
bootstrap tarballs build reproducibly even across systems and after
quite a bit of change has taken place on the master branch, and (2) even
when built from source on two separate, fresh, practically identical
Guix System machines, without using substitutes, the gcc-static binary
still differs.

Now that we have decided to use these powerpc64 bootstrap tarballs, what
are the next steps for uploading them to the GNU FTP server?  I've never
done that before, and I don't think I have access.  For now I've put a
signed copy of the powerpc64-linux (big endian) bootstrap tarballs, with
a SHA-512 hash, here:

https://media.marusich.info/guix-ppc64-bootstrap/bootstrap-tarballs-from-guix-1ced8379c7.tar.xz
https://media.marusich.info/guix-ppc64-bootstrap/bootstrap-tarballs-from-guix-1ced8379c7.tar.xz.asc
https://media.marusich.info/guix-ppc64-bootstrap/bootstrap-tarballs-from-guix-1ced8379c7.tar.xz.sha512sum

For the record, these bootstrap tarballs were built via the following
steps:

- Use
  https://ftp.gnu.org/gnu/guix/guix-system-install-1.2.0.x86_64-linux.iso.xz
  to install Guix System 1.2.0 on an x86_64-linux machine.
- Run: guix pull --no-substitutes 
--commit=1ced8379c7641788fa607b19b7a66d18f045362b
- Run: guix 

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Leo Le Bouter via Bug reports for GNU Guix]

On Tue, 2020-12-15 at 08:34 +0100, Leo Le Bouter wrote:
> On Mon, 2020-12-14 at 23:24 +0100, Ludovic Courtès wrote:
> > Yes, I think we could just cross-build those bootstrap binaries
> > from
> > current ‘master’ and be done with it, if it works for you.
> 
> Yes that would be awesome! The master branch just needs the patch
> from
> bug  - I guess
> considering it affects lots of packages it needs to be rewritten the
> same way Efraim has rewritten their PowerPC 32-bits patch. I'll look
> into that. Correct?

Rewrote patch and submitted here: <
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45252>

Thanks

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Leo Le Bouter via Bug reports for GNU Guix]

For the record, I attached the failed build log for current core-
updates.

$ ./pre-inst-env guix describe
Git checkout:
  repository: /home/lle-bout/src/guix
  branch: core-updates
  commit: cc6cb6e80a42355147809b4830053a34d1563994

Build command:

$ ./pre-inst-env guix build --target=powerpc64le-linux-gnu bootstrap-
tarballs

The most important bit in the build log is:

configure: error: ***  The compiler must support -mabi=ieeelongdouble
and -mlongdouble simultaneously.

This particular error does not happen with the GCC 7.x and Glibc 2.31
combo.


bin0lTa7yArN4.bin
Description: application/bzip

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Leo Le Bouter via Bug reports for GNU Guix]

On Mon, 2020-12-14 at 23:24 +0100, Ludovic Courtès wrote:
> Yes, I think we could just cross-build those bootstrap binaries from
> current ‘master’ and be done with it, if it works for you.

Yes that would be awesome! The master branch just needs the patch from
bug  - I guess
considering it affects lots of packages it needs to be rewritten the
same way Efraim has rewritten their PowerPC 32-bits patch. I'll look
into that. Correct?

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Ludovic Courtès]

Hi Leo,

Leo Le Bouter  skribis:

> It would be great to do that at least temporarily on master. It will
> not affect much since other architectures are bootstrapped already. We
> could also make it conditional. Reproducibility instructions will have
> to contain exact commit id and configuration for both GNU Guix System
> (x86_64-linux) and GNU Guix which can cross-compile.

Yes, I think we could just cross-build those bootstrap binaries from
current ‘master’ and be done with it, if it works for you.

Thanks,
Ludo’.

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Leo Le Bouter via Bug reports for GNU Guix]

On Mon, 2020-12-14 at 12:38 +0200, Efraim Flashner wrote:
> It looks like I mispoke, I meant gnu/packages/make-bootstrap.scm. If
> we
> change glibc-for-bootstrap to inherit glibc-2.31 then the rest of the
> bootstrap binaries should use that one and everything else will use
> the
> regular glibc.

It would be great to do that at least temporarily on master. It will
not affect much since other architectures are bootstrapped already. We
could also make it conditional. Reproducibility instructions will have
to contain exact commit id and configuration for both GNU Guix System
(x86_64-linux) and GNU Guix which can cross-compile.

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Efraim Flashner]

On Mon, Dec 14, 2020 at 11:34:35AM +0100, Leo Le Bouter wrote:
> On Mon, 2020-12-14 at 12:27 +0200, Efraim Flashner wrote:
> 
> > but I wouldn't count on
> > maintaining a separate glibc for powerpc64le vs the rest of the
> > architectures.
> 
> It doesnt need to be maintained, it only needs to work in one commit on
> master and then one uses time-machine to rebuild the bootstrap binaries
> if they wish to. The make-bootstrap code is already unmaintained for
> every architecture anyway since we never rebuild bootstrap binaries
> using later GNU Guix revisions ever.

It looks like I mispoke, I meant gnu/packages/make-bootstrap.scm. If we
change glibc-for-bootstrap to inherit glibc-2.31 then the rest of the
bootstrap binaries should use that one and everything else will use the
regular glibc.

> 
> > Do you have a preference big-endian vs little endian?
> 
> I'd like both but little endian has the widest eco-system support
> especially w.r.t. to Linux drivers. Many Linux drivers have endianness
> bugs (lack of endian-safe serialization for DMA..), it's such a plague
> that sticking to little endian is just better right now. One common
> example being mpt3sas and amdgpu drivers required in some
> configurations of the Talos II system.
> 

I remember you mentioning that.

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


signature.asc
Description: PGP signature

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Leo Le Bouter via Bug reports for GNU Guix]

On Mon, 2020-12-14 at 12:27 +0200, Efraim Flashner wrote:

> but I wouldn't count on
> maintaining a separate glibc for powerpc64le vs the rest of the
> architectures.

It doesnt need to be maintained, it only needs to work in one commit on
master and then one uses time-machine to rebuild the bootstrap binaries
if they wish to. The make-bootstrap code is already unmaintained for
every architecture anyway since we never rebuild bootstrap binaries
using later GNU Guix revisions ever.

> Do you have a preference big-endian vs little endian?

I'd like both but little endian has the widest eco-system support
especially w.r.t. to Linux drivers. Many Linux drivers have endianness
bugs (lack of endian-safe serialization for DMA..), it's such a plague
that sticking to little endian is just better right now. One common
example being mpt3sas and amdgpu drivers required in some
configurations of the Talos II system.

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Efraim Flashner]

On Mon, Dec 14, 2020 at 10:22:43AM +0100, Leo Le Bouter wrote:
> Hello Chris, Ludo and Efraim,
> 
> In my experience, the bootstrap binaries are reproducible on
> powerpc64le-linux-gnu for a specific GNU Guix System and GNU Guix
> version and configuration. It's not perfect that the kernel version has
> to be pinned for reproducibility but it's better than nothing.
> 
> The issue with powerpc64le-linux-gnu on GNU Guix core-updates now is
> that it has been upgraded to Glibc 2.32 and there is other issues due
> to that. Glibc 2.31 is otherwise working well. I wish we could push
> changes to build bootstrap binaries to master where there is Glibc 2.31
> (and ensure the changes don't affect other architectures) and get this
> over with. 

It is possible to create a "perfect setup" by editing the package
definitions in gnu/packages/bootstrap to fix certain issues which are
needed to make bootstrap binaries actually work. I suppose it would be
possible to downgrade glibc in bootstrap.scm, but I wouldn't count on
maintaining a separate glibc for powerpc64le vs the rest of the
architectures.

Do you have a preference big-endian vs little endian?

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


signature.asc
Description: PGP signature

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Leo Le Bouter via Bug reports for GNU Guix]

Hello Chris, Ludo and Efraim,

In my experience, the bootstrap binaries are reproducible on
powerpc64le-linux-gnu for a specific GNU Guix System and GNU Guix
version and configuration. It's not perfect that the kernel version has
to be pinned for reproducibility but it's better than nothing.

The issue with powerpc64le-linux-gnu on GNU Guix core-updates now is
that it has been upgraded to Glibc 2.32 and there is other issues due
to that. Glibc 2.31 is otherwise working well. I wish we could push
changes to build bootstrap binaries to master where there is Glibc 2.31
(and ensure the changes don't affect other architectures) and get this
over with. 

Leo

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Ludovic Courtès]

Hi Chris,

Chris Marusich  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’.

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Efraim Flashner]

On Sun, Dec 13, 2020 at 03:36:58PM -0800, Chris Marusich wrote:
> Hi,
> 
> I tried to do some experiments to see if this problem happens with the
> current GCC (version 10).
> 
> I built GCC 10 (not cross-compiling) on an x86_64 system using Guix with
> substitutes on Debian.  (I tried without substitutes, too, but some of
> the dependencies failed to be built for unrelated reasons.)  I then
> manually copied the /gnu/store and related files (except for the GCC 10
> output paths) from Debian onto a Fedora machine, and I rebuilt GCC 10
> there using Guix (again, not cross-compiling).  The output on Fedora was
> identical to that of Debian.  Of course, the configuration Guix uses to
> build GCC 10 is a bit different from the one used to (cross-)build the
> powerpc64-linux bootstrap GCC, but it's still an interesting data point.
> In particular, GCC 10's libstdc++.a was identical on Debian and Fedora,
> so I suppose maybe they've fixed that issue in the more recent versions.
> 
> I also tried to use Guix (the current version, from master branch - I
> ran guix pull today) to cross-build gcc-10 for the powerpc64-linux-gnu
> target on both Debian and Fedora x86_64 systems, starting from scratch
> with substitutes enabled:
> 
> guix build --target=powerpc64-linux-gnu -e '(@ (gnu packages gcc) gcc-10)'
> 
> On both Debian and Fedora, the build of gcc-10.2.0.drv failed with the
> following error:
> 
> checking for -fPIC -shared... yes
> configure: error: 
>Building GCC with plugin support requires a host that supports
>-fPIC, -shared, -ldl and -rdynamic.
> 
> This basically just means that we can't cross-build gcc-10 for
> powerpc64-linux-gnu out of the box on x86_64 with current Guix.  I was
> hoping that the builds would succeed, and I would be able to find out if
> cross-building gcc-10 in this way would create non-reproducible
> artifacts.  I was hoping maybe I could ask for help from the GCC
> community if that were the case.  But since it doesn't even build, the
> results of that experiment were not very useful.
> 
> 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.
> 
> Ludovic Courtès  writes:
> 
> > Hi Chris,
> >
> > Chris Marusich  skribis:
> >
> >> From e3d1778a86dfd171d59d91eb01417faaf63dfa17 Mon Sep 17 00:00:00 2001
> >> From: Chris Marusich 
> >> Date: Sat, 19 Sep 2020 14:25:43 -0700
> >> Subject: [PATCH] gnu: Disable libstdc++ in bootstrap GCC.
> >>
> >> Fixes part of: .
> >>
> >> * gnu/packages/make-bootstrap.scm (%gcc-static) [#:configure-flags]: Add
> >> --disable-libstdcxx to disable building the libstdc++-v3 directory.
> >
> > [...]
> >
> >> +   ;; In this GCC version, libstdc++.a is not 
> >> reproducible:
> >> +   ;; https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41669
> >> +   "--disable-libstdcxx"
> >
> > Does it have any effect with GCC > 4.7?  My understanding is that it
> > builds its libstdc++ no matter what.
> >
> > Also, if it’s just libstdc++.a that’s problematic (ordering issue in the
> > .a archive?), perhaps we can use --disable-shared?
> >
> > My 2¢ (I didn’t follow the whole discussion),
> > Ludo’.
> 
> Actually, --disable-shared is already present in the configure options.
> My understanding is that libstdc++.a is a statically linked library
> (perhaps I am mistaken...?), so I don't see why the presence or absence
> of --disable-shared would affect it.  I thought that option was just
> supposed to control whether or not to build shared libraries.
> 
> Efraim Flashner  writes:
> 
> > On Fri, Sep 25, 2020 at 11:52:48PM -0700, Chris Marusich wrote:
> >> Hi everyone,
> >> 
> >> Efraim Flashner  writes:
> >> 
> >> > Is this a file we actually need during the bootstrap process? Can we
> >> > "work around it" by just deleting it?
> 
> I've spent all of my spare Guix time trying to debug this
> reproducibility issue first, and half a year has passed without progress
> as a result.  I think we should use the bootstrap binaries we 

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Chris Marusich]

Hi,

I tried to do some experiments to see if this problem happens with the
current GCC (version 10).

I built GCC 10 (not cross-compiling) on an x86_64 system using Guix with
substitutes on Debian.  (I tried without substitutes, too, but some of
the dependencies failed to be built for unrelated reasons.)  I then
manually copied the /gnu/store and related files (except for the GCC 10
output paths) from Debian onto a Fedora machine, and I rebuilt GCC 10
there using Guix (again, not cross-compiling).  The output on Fedora was
identical to that of Debian.  Of course, the configuration Guix uses to
build GCC 10 is a bit different from the one used to (cross-)build the
powerpc64-linux bootstrap GCC, but it's still an interesting data point.
In particular, GCC 10's libstdc++.a was identical on Debian and Fedora,
so I suppose maybe they've fixed that issue in the more recent versions.

I also tried to use Guix (the current version, from master branch - I
ran guix pull today) to cross-build gcc-10 for the powerpc64-linux-gnu
target on both Debian and Fedora x86_64 systems, starting from scratch
with substitutes enabled:

guix build --target=powerpc64-linux-gnu -e '(@ (gnu packages gcc) gcc-10)'

On both Debian and Fedora, the build of gcc-10.2.0.drv failed with the
following error:

checking for -fPIC -shared... yes
configure: error: 
   Building GCC with plugin support requires a host that supports
   -fPIC, -shared, -ldl and -rdynamic.

This basically just means that we can't cross-build gcc-10 for
powerpc64-linux-gnu out of the box on x86_64 with current Guix.  I was
hoping that the builds would succeed, and I would be able to find out if
cross-building gcc-10 in this way would create non-reproducible
artifacts.  I was hoping maybe I could ask for help from the GCC
community if that were the case.  But since it doesn't even build, the
results of that experiment were not very useful.

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.

Ludovic Courtès  writes:

> Hi Chris,
>
> Chris Marusich  skribis:
>
>> From e3d1778a86dfd171d59d91eb01417faaf63dfa17 Mon Sep 17 00:00:00 2001
>> From: Chris Marusich 
>> Date: Sat, 19 Sep 2020 14:25:43 -0700
>> Subject: [PATCH] gnu: Disable libstdc++ in bootstrap GCC.
>>
>> Fixes part of: .
>>
>> * gnu/packages/make-bootstrap.scm (%gcc-static) [#:configure-flags]: Add
>> --disable-libstdcxx to disable building the libstdc++-v3 directory.
>
> [...]
>
>> +   ;; In this GCC version, libstdc++.a is not reproducible:
>> +   ;; https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41669
>> +   "--disable-libstdcxx"
>
> Does it have any effect with GCC > 4.7?  My understanding is that it
> builds its libstdc++ no matter what.
>
> Also, if it’s just libstdc++.a that’s problematic (ordering issue in the
> .a archive?), perhaps we can use --disable-shared?
>
> My 2¢ (I didn’t follow the whole discussion),
> Ludo’.

Actually, --disable-shared is already present in the configure options.
My understanding is that libstdc++.a is a statically linked library
(perhaps I am mistaken...?), so I don't see why the presence or absence
of --disable-shared would affect it.  I thought that option was just
supposed to control whether or not to build shared libraries.

Efraim Flashner  writes:

> On Fri, Sep 25, 2020 at 11:52:48PM -0700, Chris Marusich wrote:
>> Hi everyone,
>> 
>> Efraim Flashner  writes:
>> 
>> > Is this a file we actually need during the bootstrap process? Can we
>> > "work around it" by just deleting it?

I've spent all of my spare Guix time trying to debug this
reproducibility issue first, and half a year has passed without progress
as a result.  I think we should use the bootstrap binaries we built half
a year ago, and move on with life.

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 

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Efraim Flashner]

On Fri, Sep 25, 2020 at 11:52:48PM -0700, Chris Marusich wrote:
> Hi everyone,
> 
> Efraim Flashner  writes:
> 
> > Is this a file we actually need during the bootstrap process? Can we
> > "work around it" by just deleting it?
> 
> That's a good idea.  I tried building %gcc-static with the
> --disable-libstdcxx configure flag (see attached patch), and that caused
> the build of %gcc-static itself to become reproducible on Debian and
> Fedora when using exactly the same inputs.  To clarify, I have recently
> run the following experiments:
> 
> +--+-+-+--++---+
> | Case |Build|  libstdcxx  | substitutes? | Inputs |  
>   Result |
> +--+-+-+--++---+
> |  | | |  | Built fresh on |  
>   Output |
> |  1   | %gcc-static |   enabled   | yes  | Debian, copied |  
>  differs:|
> |  | | |  |   to Fedora|  
> libstdc++.a  |
> +--+-+-+--++---+
> |  | | |  | Re-used inputs |  
> Toy binary   |
> |  2   | toy program | n/a | yes  |   from above   |  
>  does not|
> |  | | |  ||  
>   differ |
> +--+-+-+--++---+
> |  | | |  | Built fresh on |  
> Output does  |
> |  3   | %gcc-static |  disabled   | yes  | Debian, copied |  
> not differ   |
> |  | | |  |   to Fedora|  
>  |
> +--+-+-+--++---+
> |  | | |  | Built fresh on |  
>   Output |
> |  4   | %gcc-static |  disabled   | yes  | Debian, fresh  |  
>  differs:|
> |  | | |  |   on Fedora| 
> various files |
> +--+-+-+--++---+
> |  | | |  | Inputs failed  | 
> Build failed  |
> |  5   | %gcc-static |  disabled   |  no  |  to build on   |  
>   on both|
> |  | | |  |  both systems  |  
>   systems|
> +--+-+-+--++---+
> 
> The "toy program" in case 2 was just this:
> 
>   #include 
>   int main() {
> printf("Hello");
> return 0;
>   }
> 
> When I say I "copied" the inputs from Debian to Fedora, I mean just
> that.  I copied stuff like /gnu and /var/guix from Debian to Fedora
> (while guix-daemon was stopped, of course), GC'd just %gcc-static on
> Fedora, and then rebuilt %gcc-static on Fedora so it would use exactly
> the same inputs as were used on Debian.
> 
> The most notable new findings are cases 3 and 4.  Case 5 made me pretty
> sad because I spent almost an entire weekend trying to build Guix from
> source using various binary Guix releases, and in none of the attempts
> was I successful in running "guix pull" or even just "guix environment
> --pure guix" without substitutes, which really surprised me.
> 
> Case 3 confirms Efraim's suggestion: we can fix the libstdc++.a
> reproducibility problem by simply not building libstdc++.a in the first
> place. It also confirms that, when built with --disable-libstdcxx,
> %gcc-static can be built reproducibly on different systems as long as
> exactly the same inputs are used.  Whether or not %gcc-static can be
> used to successfully bootstrap packages on powerpc64-linux when built in
> this way remains to be seen.
> 
> Case 4, unfortunately, demonstrates that there are still other
> reproducibility issues that we have not yet resolved.  Since the only
> difference between cases 3 and 4 is how the inputs were realized, the
> differing %gcc-static output must be caused by the inputs somehow.
> 
> In case 4, the %gcc-static output differed in the following files (the
> hashes on the left are MD5 hashes):
> 
> --8<---cut here---start->8---
> --- /dev/fd/632020-09-25 20:35:33.386554595 -0700
> +++ /dev/fd/622020-09-25 20:35:33.387554604 -0700
> @@ -1,28 +1,28 @@
> -c9b0dfcbad566c0b8b88df94bb993312  ./bin/c++
> -092823145dc96b9eb8362f7b4ced  ./bin/cpp
> -c9b0dfcbad566c0b8b88df94bb993312  ./bin/g++
> -e4cc43b7790dcd25f31419bad606b36e  ./bin/gcc
> +8f02302b55643f1c711e472a42fea8bd  ./bin/c++
> +9f1fd993e4f2b796fcc56f0b2f8a47d2  ./bin/cpp
> +8f02302b55643f1c711e472a42fea8bd  ./bin/g++
> 

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Ludovic Courtès]

Hi Chris,

Chris Marusich  skribis:

> From e3d1778a86dfd171d59d91eb01417faaf63dfa17 Mon Sep 17 00:00:00 2001
> From: Chris Marusich 
> Date: Sat, 19 Sep 2020 14:25:43 -0700
> Subject: [PATCH] gnu: Disable libstdc++ in bootstrap GCC.
>
> Fixes part of: .
>
> * gnu/packages/make-bootstrap.scm (%gcc-static) [#:configure-flags]: Add
> --disable-libstdcxx to disable building the libstdc++-v3 directory.

[...]

> +   ;; In this GCC version, libstdc++.a is not reproducible:
> +   ;; https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41669
> +   "--disable-libstdcxx"

Does it have any effect with GCC > 4.7?  My understanding is that it
builds its libstdc++ no matter what.

Also, if it’s just libstdc++.a that’s problematic (ordering issue in the
.a archive?), perhaps we can use --disable-shared?

My 2¢ (I didn’t follow the whole discussion),
Ludo’.

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Chris Marusich]

Hi everyone,

Efraim Flashner  writes:

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

That's a good idea.  I tried building %gcc-static with the
--disable-libstdcxx configure flag (see attached patch), and that caused
the build of %gcc-static itself to become reproducible on Debian and
Fedora when using exactly the same inputs.  To clarify, I have recently
run the following experiments:

+--+-+-+--++---+
| Case |Build|  libstdcxx  | substitutes? | Inputs |
Result |
+--+-+-+--++---+
|  | | |  | Built fresh on |
Output |
|  1   | %gcc-static |   enabled   | yes  | Debian, copied |   
differs:|
|  | | |  |   to Fedora|  
libstdc++.a  |
+--+-+-+--++---+
|  | | |  | Re-used inputs |  
Toy binary   |
|  2   | toy program | n/a | yes  |   from above   |   
does not|
|  | | |  ||
differ |
+--+-+-+--++---+
|  | | |  | Built fresh on |  
Output does  |
|  3   | %gcc-static |  disabled   | yes  | Debian, copied |  
not differ   |
|  | | |  |   to Fedora|
   |
+--+-+-+--++---+
|  | | |  | Built fresh on |
Output |
|  4   | %gcc-static |  disabled   | yes  | Debian, fresh  |   
differs:|
|  | | |  |   on Fedora| 
various files |
+--+-+-+--++---+
|  | | |  | Inputs failed  | 
Build failed  |
|  5   | %gcc-static |  disabled   |  no  |  to build on   |
on both|
|  | | |  |  both systems  |
systems|
+--+-+-+--++---+

The "toy program" in case 2 was just this:

  #include 
  int main() {
printf("Hello");
return 0;
  }

When I say I "copied" the inputs from Debian to Fedora, I mean just
that.  I copied stuff like /gnu and /var/guix from Debian to Fedora
(while guix-daemon was stopped, of course), GC'd just %gcc-static on
Fedora, and then rebuilt %gcc-static on Fedora so it would use exactly
the same inputs as were used on Debian.

The most notable new findings are cases 3 and 4.  Case 5 made me pretty
sad because I spent almost an entire weekend trying to build Guix from
source using various binary Guix releases, and in none of the attempts
was I successful in running "guix pull" or even just "guix environment
--pure guix" without substitutes, which really surprised me.

Case 3 confirms Efraim's suggestion: we can fix the libstdc++.a
reproducibility problem by simply not building libstdc++.a in the first
place. It also confirms that, when built with --disable-libstdcxx,
%gcc-static can be built reproducibly on different systems as long as
exactly the same inputs are used.  Whether or not %gcc-static can be
used to successfully bootstrap packages on powerpc64-linux when built in
this way remains to be seen.

Case 4, unfortunately, demonstrates that there are still other
reproducibility issues that we have not yet resolved.  Since the only
difference between cases 3 and 4 is how the inputs were realized, the
differing %gcc-static output must be caused by the inputs somehow.

In case 4, the %gcc-static output differed in the following files (the
hashes on the left are MD5 hashes):

--8<---cut here---start->8---
--- /dev/fd/63  2020-09-25 20:35:33.386554595 -0700
+++ /dev/fd/62  2020-09-25 20:35:33.387554604 -0700
@@ -1,28 +1,28 @@
-c9b0dfcbad566c0b8b88df94bb993312  ./bin/c++
-092823145dc96b9eb8362f7b4ced  ./bin/cpp
-c9b0dfcbad566c0b8b88df94bb993312  ./bin/g++
-e4cc43b7790dcd25f31419bad606b36e  ./bin/gcc
+8f02302b55643f1c711e472a42fea8bd  ./bin/c++
+9f1fd993e4f2b796fcc56f0b2f8a47d2  ./bin/cpp
+8f02302b55643f1c711e472a42fea8bd  ./bin/g++
+583d1b011a7ba009d7385117dd7a33c8  ./bin/gcc
 f9d94f4bb61f70d14ea4b2ce73c9be9d  ./bin/gcc-ar
 01fc2184f99c558771aa8f2fe30b373d  ./bin/gcc-nm
 da5356ee09ccda4ca06758d056370f7e  ./bin/gcc-ranlib
-98645f7b00ba185e713915099853fd37  ./bin/gcov
-37dd62589454703ae7f2eaac1668b66e  

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Efraim Flashner]

On Sat, Sep 12, 2020 at 07:53:04PM -0700, Chris Marusich wrote:
> Hi everyone,
> 
> Chris Marusich  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  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Chris Marusich]

Hi everyone,

Chris Marusich  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

[Jack Hill]

On Tue, 9 Jun 2020, Chris Marusich wrote:


- Try building with different kernel versions on the same machine, to
 see if they differ.


I've done the rebuild after updated from Linux 5.4.41 to 5.4.45, and go 
identical results to my previous build. I am using a different kernel 
configuration than Guix's default kernel, but it was the same between the 
builds.


Best,
Jack

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Bengt Richter]

Hi Chris, et al,

On +2020-06-09 23:15:01 -0700, Chris Marusich wrote:
> Hi Vincent and everyone,
> 
> Vincent Legoll  writes:
> 
> > Is that showing the same (or a similar) problem :
> >
> > https://data.guix-patches.cbaines.net/gnu/store/0lcbxpw1vrca02dzpzw2rxhad7pn4zw7-gcc-objc-5.5.0
> >
> > ?
> 
> Can you clarify what you mean?  I'm not sure what you're referring to.
> 
> Chris Marusich  writes:
> 
> > At present, it seems possible that within the context of a single
> > machine, gcc-stripped-tarball-5.5.0.drv builds reproducibly, but on a
> > different machine, it may (reproducibly) build a different output.
> > I'm a bit paranoid about making mistakes, so I'll perform another full
> > GC and then try yet again to build gcc-stripped-tarball-5.5.0.drv in
> > order to verify whether it truly produces the same output when all (or
> > nearly all) of its inputs are rebuilt from scratch.
> 
> I repeated the experiment on the same machine (it took a day or two to
> build), and the result was the same: on my machine,
> gcc-stripped-tarball-5.5.0.drv builds identical output to what it built
> before. To be clear, using Guix 8159ce1970d91567468cf1bacac313099a009d2a
> on an x86_64-linux machine, I tried (yet again) the following steps:
>
[...]

> Efraim's diff looks a little different in statx.h, even though he used
> the same Guix commit as me.  Maybe this is because he cross-compiled on
> an aarch64-linux machine, while I cross-compiled on an x86_64-linux
> machine.  In the other cases, it looks like the binary files differ in
> basically the same ways.  I will share some examples below.
> 
> Here is some diffoscope output between my c++ and Efraim's (many other
> sections also differed in similarly cryptic ways):
> 
[...]

> 
> If I'm reading this correctly, one problem seems to be that our GCC
> toolchains are putting symbols at different locations.  This issue (and
> maybe others) could be trickling down, causing other aspects of the
> binaries to differ (e.g., in length).  Nothing really stands out, but
> when we discussed this on IRC, we thought perhaps factors like the
> following might contribute to the non-reproducibility:
> 
> - Perhaps we are all running different Linux kernel versions?  In some
>   cases, the kernel version can unfortunately influence the build
>   output, so this might be worth testing.
> 
> - Perhaps the GCC Makefiles etc. are doing something non-deterministic?
>

Questions triggered in my mind:

Where are respective machines getting their rules for packing and
aligning structs and unions?

Is any struct or rule/flags source dynamically generated, where different
rules could come from different defaults, or .configs, or even invalid
memoizations jumping domains?

Could pointer arithmetic get done in one domain and the offset be
misused in another? Wrong C preprocessor?

Difference in sort key comparisons for canonicalization of ordering?

Hope that's not all red herrings :)
Sorry for the noise otherwise.

> - Something else?

Hm, some race condition between processes that should be order-independent
but are not.

Then if different hardware components on different systems -- disks, memory,
processors -- cause different but repeatable patterns of waits (convoying?)
you could get repeatable but different builds.

I guess you'd have to figure out which order was really right, and force
the order of processing explicitly to that order, so all systems would
do it that way.

> 
> Avenues of investigation:
> 
> - If anything obvious stands out from the diffoscope output, please
>   leave a comment.
> 
> - Try building with different kernel versions on the same machine, to
>   see if they differ.
> 
> - If somebody else could please confirm that running the following
>   command reports no difference on their own machine (i.e., exit code
>   0), that would be good to know, since it would help further solidify
>   the theory that on a single machine, the build of gcc-static-5.5.0.drv
>   is reproducible, even if it is not reproducible across machines:
> 
>   guix build --no-substitutes --check --target=powerpc64-linux-gnu \
>-e '(@@ (gnu packages make-bootstrap) %gcc-static)'
> 
> - Try building two different versions of gcc-7.5.0 (maybe by hand?), and
>   then use them to build a simple reproduction case and compare results.
>   If we're lucky, maybe this will help us understand the problem better.
> 
> We'll get there!
> 
> -- 
> Chris

-- 
Regards,
Bengt Richter

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Chris Marusich]

Hi Vincent and everyone,

Vincent Legoll  writes:

> Is that showing the same (or a similar) problem :
>
> https://data.guix-patches.cbaines.net/gnu/store/0lcbxpw1vrca02dzpzw2rxhad7pn4zw7-gcc-objc-5.5.0
>
> ?

Can you clarify what you mean?  I'm not sure what you're referring to.

Chris Marusich  writes:

> At present, it seems possible that within the context of a single
> machine, gcc-stripped-tarball-5.5.0.drv builds reproducibly, but on a
> different machine, it may (reproducibly) build a different output.
> I'm a bit paranoid about making mistakes, so I'll perform another full
> GC and then try yet again to build gcc-stripped-tarball-5.5.0.drv in
> order to verify whether it truly produces the same output when all (or
> nearly all) of its inputs are rebuilt from scratch.

I repeated the experiment on the same machine (it took a day or two to
build), and the result was the same: on my machine,
gcc-stripped-tarball-5.5.0.drv builds identical output to what it built
before. To be clear, using Guix 8159ce1970d91567468cf1bacac313099a009d2a
on an x86_64-linux machine, I tried (yet again) the following steps:

- I deleted as much as I could from the store using 'guix gc'.

- I explicitly verified that all outputs for the following derivations
  no longer existed in the store:

  /gnu/store/pygln3lr6qbxcps3kmn3w4bc0d0nlpd3-gcc-stripped-tarball-5.5.0.drv
  /gnu/store/kcv3ja1rfr93hw6ly51878zjhdwpgv7z-gcc-stripped-5.5.0.drv
  /gnu/store/m9hfwppla8lph0vxa15lfkp81s2bbjjs-gcc-static-5.5.0.drv
  /gnu/store/g9fpkg2qa27mka1znqsvx8vxqyabsj2y-gcc-7.5.0.drv

- I then built gcc-stripped-tarball-5.5.0.drv via the following command:

  guix build --no-substitutes --check --target=powerpc64-linux-gnu \
   -e '(@@ (gnu packages make-bootstrap) %gcc-static)'

This rebuilt basically everything, including gcc-7.5.0.drv and the other
derivations mentioned above.  When I checked the built output of the
gcc-stripped-tarball-5.5.0.drv derivation, I found that its SHA-512 hash
was identical to the one I calculated previously, which was:

--8<---cut here---start->8---
8aca7f332a1ba8e3c2225c161a7545b0a04ddd690d164dc97afee9c9ea067b0c49bc155e9f06d285c22e24cdd16d91e59730af5f1dd9efcda13a26bede5948a2
  
/gnu/store/rsmhiyplmbiqm1qwniiafi4ak76pd61v-gcc-stripped-tarball-5.5.0/gcc-stripped-5.5.0-powerpc64-linux-gnu.tar.xz
--8<---cut here---end--->8---

Anyway, this confirms what we already knew: GCC builds reproducibly on
my machine, but it is different when other people build it on other
machines.  I'm now quite convinced of this fact.

Jack and Vincent shared their build results on the email list.  For
reference, you can get them here:

https://flashner.co.il/~efraim/gcc-stripped-5.5.0-powerpc64-linux-gnu.tar.xz
https://jackhill.us/misc/gcc-stripped-5.5.0-powerpc64-linux-gnu.tar.xz
https://media.marusich.info/gcc-stripped-5.5.0-powerpc64-linux-gnu.tar.xz

I also received a copy of Vincent's build results via private email.  In
short, they all seem to differ in basically the same ways:

--8<---cut here---start->8---
[1] marusich@garuda-lan:~/Documents/notes/guix/ppc/gcc-stripped-tarballs
$ diff -r chris jack
Binary files chris/bin/c++ and jack/bin/c++ differ
Binary files chris/bin/cpp and jack/bin/cpp differ
Binary files chris/bin/g++ and jack/bin/g++ differ
Binary files chris/bin/gcc and jack/bin/gcc differ
Binary files chris/bin/gcov and jack/bin/gcov differ
Binary files chris/bin/gcov-dump and jack/bin/gcov-dump differ
Binary files chris/bin/gcov-tool and jack/bin/gcov-tool differ
Binary files chris/bin/powerpc64-linux-gnu-c++ and 
jack/bin/powerpc64-linux-gnu-c++ differ
Binary files chris/bin/powerpc64-linux-gnu-g++ and 
jack/bin/powerpc64-linux-gnu-g++ differ
Binary files chris/bin/powerpc64-linux-gnu-gcc and 
jack/bin/powerpc64-linux-gnu-gcc differ
Binary files chris/bin/powerpc64-linux-gnu-gcc-5.5.0 and 
jack/bin/powerpc64-linux-gnu-gcc-5.5.0 differ
Binary files chris/lib/libstdc++.a and jack/lib/libstdc++.a differ
Binary files chris/libexec/gcc/powerpc64-linux-gnu/5.5.0/cc1 and 
jack/libexec/gcc/powerpc64-linux-gnu/5.5.0/cc1 differ
Binary files chris/libexec/gcc/powerpc64-linux-gnu/5.5.0/cc1plus and 
jack/libexec/gcc/powerpc64-linux-gnu/5.5.0/cc1plus differ
Binary files chris/libexec/gcc/powerpc64-linux-gnu/5.5.0/collect2 and 
jack/libexec/gcc/powerpc64-linux-gnu/5.5.0/collect2 differ
Binary files chris/libexec/gcc/powerpc64-linux-gnu/5.5.0/lto-wrapper and 
jack/libexec/gcc/powerpc64-linux-gnu/5.5.0/lto-wrapper differ
[1] marusich@garuda-lan:~/Documents/notes/guix/ppc/gcc-stripped-tarballs
$ diff -r chris vincent
Binary files chris/bin/c++ and vincent/bin/c++ differ
Binary files chris/bin/cpp and vincent/bin/cpp differ
Binary files chris/bin/g++ and vincent/bin/g++ differ
Binary files chris/bin/gcc and vincent/bin/gcc differ
Binary files chris/bin/gcov and vincent/bin/gcov differ
Binary files chris/bin/gcov-dump and 

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Vincent Legoll]

Is that showing the same (or a similar) problem :

https://data.guix-patches.cbaines.net/gnu/store/0lcbxpw1vrca02dzpzw2rxhad7pn4zw7-gcc-objc-5.5.0

?

--
Vincent Legoll

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Chris Marusich]

Hi all,

Chris Marusich  writes:

> The derivation that produced the differing output was:
>
> /gnu/store/pygln3lr6qbxcps3kmn3w4bc0d0nlpd3-gcc-stripped-tarball-5.5.0.drv
>
> On my x86_64-linux system, twice I tried running "guix build --check" on
> this derivation, but each time it surprisingly reported no difference.

This derivation corresponds to %gcc-bootstrap-tarball from (gnu packages
make-bootstrap), which just creates a tarball of the output of
%gcc-stripped.  Therefore, it's not too surprising that it's
reproducible.  Similarly, %gcc-stripped just strips some store
references from the output of %gcc-static.  The %gcc-static package is
more interesting: it's where we actually build the statically linked
bootstrap GCC (which is then stripped and packed into a tarball as
mentioned above), so I thought that it might be where the
non-determinism is coming from.  However, I haven't yet pinpointed the
problem.

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.

I hoped to find more information by invoking "guix build --check" on
every input of gcc-static-5.5.0.drv.  When I tried that, what I found
was that all of its inputs build reproducibly except the following two:

/gnu/store/x32cnfkd50fnxs10xp1jdn24h7ai2gxr-guile-3.0.2.drv
/gnu/store/g9fpkg2qa27mka1znqsvx8vxqyabsj2y-gcc-7.5.0.drv

I haven't investigated guile-3.0.2.drv.  However, gcc-7.5.0.drv felt
more suspicious to me, and it is actually the derivation that builds
gcc-final from (gnu packages commencement), which you can see via:

guix build -d -e '(@@ (gnu packages commencement) gcc-final)'

Using "guix gc", I deleted the outputs of
gcc-stripped-tarball-5.5.0.drv, gcc-stripped-5.5.0.drv,
gcc-static-5.5.0.drv, and gcc-7.5.0.drv.  I then tried building these
four derivations again (without substitutes, the same as before).
Before doing this, I stored the SHA-512 hashes of their output files,
and after the build succeeded, I compared the hashes of the new files
with the previous values.  I found that these derivations' newly rebuilt
outputs were identical to their original values, except for
gcc-7.5.0.drv, which produced some different files.  Most significantly,
this means that gcc-stripped-tarball-5.5.0.drv produced the exact same
tarball for me as it did the first time I built it, even though some of
its inputs are not themselves reproducible.

At present, it seems possible that within the context of a single
machine, gcc-stripped-tarball-5.5.0.drv builds reproducibly, but on a
different machine, it may (reproducibly) build a different output.  I'm
a bit paranoid about making mistakes, so I'll perform another full GC
and then try yet again to build gcc-stripped-tarball-5.5.0.drv in order
to verify whether it truly produces the same output when all (or nearly
all) of its inputs are rebuilt from scratch.

Some people have also shared their differing copies of the binaries on
the email list.  It could be productive to compare the contents with
diffoscope, although I suspect the diff might be too large to be useful.

-- 
Chris


signature.asc
Description: PGP signature

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Chris Marusich]

Hi,

As demonstrated in the following email thread, the powerpc64-linux
bootstrap-tarballs are not reproducible when cross-compiled from an
x86_64-linux system:

https://lists.gnu.org/archive/html/guix-devel/2020-06/msg3.html

Four people attempted to invoke the following command using Guix commit
8159ce1970d91567468cf1bacac313099a009d2a:

  guix build --no-substitutes --target=powerpc64-linux-gnu bootstrap-tarballs

All of the bootstrap tarballs except for gcc-stripped were reproducible.
However, these attempts produced four different versions of
gcc-stripped-5.5.0-powerpc64-linux-gnu.tar.xz.  At least two of the
attempts were performed on two different x86_64-linux systems.

The derivation that produced the differing output was:

/gnu/store/pygln3lr6qbxcps3kmn3w4bc0d0nlpd3-gcc-stripped-tarball-5.5.0.drv

You can build this derivation in a variety of ways, for example:

  guix build --target=powerpc64-linux-gnu -e '(@ (gnu packages make-bootstrap) 
%gcc-bootstrap-tarball)'

or just

  guix build 
/gnu/store/pygln3lr6qbxcps3kmn3w4bc0d0nlpd3-gcc-stripped-tarball-5.5.0.drv

On my x86_64-linux system, twice I tried running "guix build --check" on
this derivation, but each time it surprisingly reported no difference.
Out of paranoia, I tried deleting its output with "guix gc --delete",
and then building it again.  The new output was, indeed, identical to
the old output.  This makes me think that the non-reproducibility is
coming from something outside the immediate build logic of the
gcc-stripped-tarball-5.5.0.drv derivation itself.

I will next try to rebuild everything from scratch again.  I will also
try to get copies of the differing outputs from the people involved in
that email thread, in order to run diffoscope on them.

-- 
Chris


signature.asc
Description: PGP signature