On 6/11/18, Jeff Law wrote:
> On 06/11/2018 11:06 AM, 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 po
On 06/11/2018 11:06 AM, 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
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
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 variant.
--
Joseph S. Myers
jos...@codesourcery.co
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
