diff mbox series

ltmain.sh: Sort input file list

Message ID 20180609192028.4511-1-bwiedemann@suse.de
State New
Headers show
Series ltmain.sh: Sort input file list | expand

Commit Message

Bernhard M. Wiedemann June 9, 2018, 7:20 p.m. UTC 
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 build in resulting binaries like gccgo, cc1obj and cpp
because the order of objects in libstdc++.a varied based on
the order of entries returned by the filesystem.

Two remaining issues are with timestamps in the ada build
and with profiledbootstrap that only is reproducible if all inputs
in the profiling run remain constant (which is not the case)

Testcases:
  none included because patch is trivial and it would need to compare builds on 2 filesystems.

ChangeLog:
  ltmain.sh: sort list of object files to make build reproducible

Bootstrapping and testing:
  tested successfully with gcc8 on x86_64
---
 ltmain.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Joseph Myers June 11, 2018, 5:06 p.m. UTC | #1 
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.
Bernhard M. Wiedemann June 11, 2018, 6:45 p.m. UTC | #2 
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 variant.

right. Either variant should be fine.

Cherry-picking it, is the safe variant.
Jeff Law June 11, 2018, 6:47 p.m. UTC | #3 
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 variant.
> 
Agreed.  My preference would be to get the various libtool, autoconf and
friends updated from the appropriate upstream projects.

jeff
Eric Gallager June 12, 2018, 1:50 a.m. UTC | #4 
On 6/11/18, Jeff Law <law@redhat.com> 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 possible, rather than having our own variant.
>>
> Agreed.  My preference would be to get the various libtool, autoconf and
> friends updated from the appropriate upstream projects.
>
> jeff
>

Thread from the last time this came up is here:
https://gcc.gnu.org/ml/gcc/2017-10/msg00060.html
diff mbox series

Patch

diff --git a/ltmain.sh b/ltmain.sh
index 9503ec85d..96311a12c 100644
--- a/ltmain.sh
+++ b/ltmain.sh
@@ -2932,7 +2932,7 @@  func_extract_archives ()
         func_extract_an_archive "$my_xdir" "$my_xabs"
 	;;
       esac
-      my_oldobjs="$my_oldobjs "`find $my_xdir -name \*.$objext -print -o -name \*.lo -print | $NL2SP`
+      my_oldobjs="$my_oldobjs "`find $my_xdir -name \*.$objext -print -o -name \*.lo -print | LC_ALL=C sort | $NL2SP`
     done
 
     func_extract_archives_result="$my_oldobjs"