On May 4, 2006, at 11:58 AM, Andrew Haley wrote:
Mattias Brändström writes:
Ian Lance Taylor wrote:
Andrew Haley <aph@xxxxxxxxxx> 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@xxxxxxxxxx" 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.
