[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Repeatable checksums on object files + Shared Objects

From: Paul
Subject: Re: Repeatable checksums on object files + Shared Objects
Date: Thu, 30 Dec 2010 21:26:53 -0800 (PST)
User-agent: G2/1.0

On Nov 30, 8:55 am, Jeff Kilpatrick <> 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  <>
        (compare_ctor, compare_dtor): Move to ipa.c; use DECL_UID to
        sort; reverse order of constructors.

2010-05-20  Kenneth Zadeck  <>

        PR bootstrap/43870
        * df-scan.c (df_ref_compare): Stabilize sort.

2010-04-16  Doug Kwan  <>

        * 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  <>

        PR tree-optimization/42157
        * tree-sra.c (compare_access_positions): Stabilize sort if
        accesses have integer types, return zero immediately if they
are the

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,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]