> At my work place, we have a business requirement to produce
> reproducible builds and build artifacts. That is, all our .o's
> and .so's must have consistent checksums, when using the same compiler
> and libraries, across multiple builds, with no code changes. In
> practice, this works the majority of the time. We do hundreds of
> builds a week with repeatable checksums.
> However, from time to time, the checksums don't match. Using objdump -
> x, we have isolated the problem to the index number of some symbols,
> where two symbols will switch spots.
> For example:
> 100 Symbol1
> 101 Symbol2
> would appear:
> 100 Symbol2
> 101 Symbol1
Your post lacks important specifics. Does the checksum mismatch happen
in object files (in which case it's a compiler bug), or in linked
shared libraries or executables (in which case it is a linker bug
(assuming input objects are identical)).
> Is there any way to take it deeper to find out why on some machines,
It will likely happen on the same machine as well, if you try hard
enough. Several such bugs have recently been fixed in GCC. For
example, from gcc/ChangeLog:
2010-08-20 Jan Hubicka <jh@suse...>
(compare_ctor, compare_dtor): Move to ipa.c; use DECL_UID to
sort; reverse order of constructors.
* tree-ssa-reassoc.c (struct operand_entry): Add new field
(sort_by_operand_rank): Stabilize qsort comparator by using
(oecount_cmp): Stabilize qsort comparotor by using unique IDs.