Same binary, different md5sums

[Perry Smith]

On May 4, 2006, at 11:58 AM, Andrew Haley wrote:

> Mattias Brändström writes:
>> Ian Lance Taylor wrote:
>>> Andrew Haley <aph@redhat.com> writes:
>>>
>>>
>>>> That's interesting.  As far as I'm aware we have never  
>>>> guaranteed that
>>>> gcc/binutils will generate binary reproducible output, but there  
>>>> must
>>>> be a reason for any differences.
>>>
>>>
>>> A side comment: we used to guarantee that, and we used it to verify
>>> the whole set of > tools along the lines of gcc's bootstrap compare.
>>> For example, search for "gnu@cygnus.com" in bfd/coffcode.h.
>>
>> If I compile with -frandom-seed I seem to get the exact binary every
>> time. Is there any other ways that the binaries can differ? (Apart  
>> from
>> __DATE__ and other time dependent macros.)
>>
>> In my current project it currently looks like we, for certification
>> purposes, need to be able to show that our source code will produce
>> the exact same binaries that are installed on a system. Yesterday I
>> manged to get our current code and build scripts generate the
>> binaries with identical md5sums from two consecutive builds with
>> the use of -frandom-seed. So it seems that our current version of
>> gcc works fine for us. I guess my question is this: how likely is
>> this to change in the future and might there be another scenario
>> where gcc will output different binaries (with respect to md5sum)
>> today?
>
> It's not very likely.  Apart from the deliberate randmization that
> you've found, differences would probably be due to bugs such as, for
> example, binutils leaving uninitialized holes in the output files.
>
> Even if something like this does happen in the future, this is free
> software, so you'll be able to fix it.

Also, you can "certify" the compiler before switching from the  
version that you have now to a later one.  The place I worked, stuck  
with the same compiler until major releases (of their software) and  
then switched compilers (if they needed to) at that point.