On 2018-06-29 17:09, Jeff Law wrote:
> In the immediate term, applying the patch to both instances seems wise.
>
> Bernhard, do you have commit privs?
no, and I dont really want privs, since I expect to be doing only a few
patches for gcc.
Can you (or someone else) please commit the patch?
profiling run remain constant (and make -j breaks it too)
Testcases:
none included because patch is trivial and it would need to compare builds on
2 filesystems.
Bootstrapping and testing:
tested successfully with gcc8 on x86_64
[gcc]
2018-06-19 Bernhard M. Wiedemann
libtool: Sort
profiling run remain constant
Testcases:
none included because patch is trivial and it would need to compare builds on
2 filesystems.
Bootstrapping and testing:
tested successfully with gcc8 on x86_64
[gcc]
2018-06-19 Bernhard M. Wiedemann
libtool: Sort output of 'find'
On 2018-06-11 17:06, Joseph Myers wrote:
> If we're not doing a general update from upstream libtool, I think we
> should use the upstream ltmain.sh fix (libtool commit
> 74c8993c178a1386ea5e2363a01d919738402f30, it looks like), or follow it as
> close as possible, rather than having our own var
so that gcc builds in a reproducible way
in spite of indeterministic filesystem readdir order
See https://reproducible-builds.org/ for why this is good.
While working on the reproducible builds effort, I found that
when building the gcc8 package for openSUSE, there were differences
between each b
