On Nov 30, 8:55 am, Jeff Kilpatrick <kilpatrick.j...@gmail.com> wrote:
> 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 <j...@suse.cz>
...
(compare_ctor, compare_dtor): Move to ipa.c; use DECL_UID to
stabilize
sort; reverse order of constructors.
2010-05-20 Kenneth Zadeck <zad...@naturalbridge.com>
PR bootstrap/43870
* df-scan.c (df_ref_compare): Stabilize sort.
2010-04-16 Doug Kwan <dougk...@google.com>
* tree-ssa-reassoc.c (struct operand_entry): Add new field
ID. ...
(sort_by_operand_rank): Stabilize qsort comparator by using
unique IDs.
...
(oecount_cmp): Stabilize qsort comparotor by using unique IDs.
2010-01-07 Martin Jambor <mjam...@suse.cz>
PR tree-optimization/42157
* tree-sra.c (compare_access_positions): Stabilize sort if
both
accesses have integer types, return zero immediately if they
are the
same.
You didn't specify which version of GCC you are using, but it's quite
likely you are missing some or all of the changes above.
> the symbols are in the first order, while other machines (with same
> dependency, OS, compilers, etc) produce the second order? Or is their
> a way to tell g++ symbols in a particular order?
No. Note that symbol ordering is just one of possible instabilities.
I've also seen instruction order changes.
Hope this helps,
_______________________________________________
help-gplusplus mailing list
help-gplusplus@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gplusplus
