Hi Carl,

Thank you so much for looking into this!  The patch looks reasonable to
me.  I am definitely curious to try a fixed version of GCC (8 or
otherwise) to see if it helps to solve 41669!

Carl Dong <contact@carldong.me> writes:

> Here's a v2 of the patch, let me know if this suffices!
>
>> Well done.  Did you observe it in practice?  (On ‘core-updates’ maybe?)
>
> Thanks! Yes, we observed it when switching back from gcc-9 to gcc-8 for
> compiling Bitcoin Core. We use -static-libstdc++, which means that any
> non-reproducibility in libstdc++.a propagates into our produced binaries as
> well.
>
> To be clear, I was only able to identify the problem and fix thanks to your
> patch here:
> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/dico-libtool-deterministic.patch?h=b6094b1f0a6760b9f5296364cf5edb8a2e64953c
>
>
>> I’m surprised that this is still an issue since this was fixed in
>> Libtool proper long ago, probably before GCC 8 was released.
>
> Right, unfortunately GCC maintains their own version of libtool, which hasn't
> been synced with upstream for a while. I documented the details here:
> https://reproducible-builds.org/docs/archives/#gnu-libtool
>
>> The patch is big, but it looks like using ‘substitute*’ wouldn’t be an
>> easy task, so maybe it’s better this way.  WDYT?
>
> Right, I think it'd be hard to construct a robust substitute* for this that
> doesn't have false negatives/positives.

I agree; a patch seems best.

> ---
>
> This fixes the nonreproducibility in gcc documented here:
> https://reproducible-builds.org/docs/archives/#gnu-libtool
>
> * gnu/packages/patches/gcc-8-sort-libtool-find-output.patch: New patch.
> * gnu/local.mk (dist_patch_DATA): Register it.
> * gnu/packages/gcc.scm (gcc-8)[source]: Apply it.

Can this patch also be applied to earlier versions of GCC, such as
gcc-7, which is currently the default GCC used for basically everything
on Guix's master branch?  Or is it too different?

-- 
Chris