Change:
sha256 = "0sd52c898msqg7m316zp0ryyj7l326cjcn2y19dcxqp15r74qj0g"; }) ../11/fix-struct-redefinition-on-glibc-2.36.patch <ins> ../install-info-files-serially.patch </ins> ] ++ optional (targetPlatform != hostPlatform) ../libstdc++-target.patch ++ optional noSysDirs ../no-sys-dirs.patch ++ optional (noSysDirs && hostPlatform.isRiscV) ../no-sys-dirs-riscv.patch

Discussion:
Building this package twice does not produce the bit-by-bit identical result each time, making it harder to detect CI breaches. You can read more about this at https://reproducible- . Fixing bit-by-bit reproducibility also has additional advantages, such as avoiding hard-to-reproduce bugs, making content-addressed storage more effective and reducing rebuilds in such systems. You can use to analyze the differences in the output of the two builds. To view the build log of the build that produced the artifact in the binary cache: An example of a diff can be found at (in which was built from )
Diff says it comes from file (an index file). I wonder how many tiles it's expected to be ran against the directory: 1 per file (then install order parallelism causes unstable index), 1 per directory with reliance on file order on file system, or inherent non-determinism.
Yeah, it's a per-file registration. Two builds: Note how file order is slightly different here. I think we can work it around by removing and regenerating file with something like and rely on shell globs to do sorting for us.
(also found in the 'regular' gcc build: )
So the saillant bit is in : I guess the root cause of the issue is that the rule does not only output to , but also modifies as a side effect. I guess we could restructure the Makefile to install the makefile in a deterministic order, but I wonder if parallelism in the install phase is useful at all for gcc - might be OK to disable it entirely?
does quite a bit of relinking and file copying in the install phase. I would suggest keeping install phase parallel. Changing makefiles might be complicated as it's a recursive makefile with different compiler frontends ( and ). They ought to build and install independently (in parallel). On top of that regeneration requires autotools dependencies for which makes bootstrap a bit trickier. might be a less invasive way to do it. And I think it's generic enough that could be implemented as a hook for more packages.
:+1: It seems the gcc sources already don't have a , so aren't we already (re)generating them? That's a good point. It seems the info files are already first generated into and then somehow moved to - it's not obvious to me where that happens, though?

is generated from at time. is committed into 's and is generated from (and ) ( is a program written in , somewhat heavy on depends). output is split out for derivations with at
I wonder if itself could be fixed to generate consistent files regardless of the registration order of files to it. It feels like that would be the best place to fix it properly. No idea if structure allows an extension for such mode.
Looking closer, it looks like already doesn't use the input order, but puts items in alphabetical order. The problem is the 'left' side is missing entries. I wonder if supports multiple parallel processes trying to write to the same ?
seems simple enough, and indeed reads/writes the dir file without any protection against parallel processes...
I filed upstream to track proper resolution.
Thanks! I hadn't found the time to figure out whether the problem was in gcc or further upstream in the autoconf/automake/etc templates (and wasn't sure gcc would welcome reports for such possibly-upstream problems). Great to track a proper solution :+1: