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. Andrew.
