8

When compiling using G++ GNU compiler every time I do a build, without changing source code I get a different binary object file. Is there a compile option that will give me the same binary each time.

Ciro Santilli OurBigBook.com
  • 347,512
  • 102
  • 1,199
  • 985
user502603
  • 83
  • 1
  • 3

2 Answers2

14

Copied from the GCC man-page:

-frandom-seed=string
This option provides a seed that GCC uses when it would otherwise use random numbers. It is used to generate certain symbol names that have to be different in every compiled file. It is also used to place unique stamps in coverage data files and the object files that produce them. You can use the -frandom-seed option to produce reproducibly identical object files.

The string should be different for every file you compile.

Zan Lynx
  • 53,022
  • 10
  • 79
  • 131
0

You should better use make. This way if your source didn't change, the compilation will be skipped, so the object files won't be changed.

Edit: after some thinking, it's possible to address your comment with the makefile which separates preprocessing and actual compilation. and some dirty tricks.

Example makefile:

all: source

source: source.i.cpp
    @cmp -s source.i.cpp source.i.prev || g++ source.i.cpp -o source
    @touch source
    @cp source.i.cpp source.i.prev

source.i.cpp: source.cpp
    @g++ -E source.cpp >source.i.cpp

Please note the the executable's time is changed, but the contents not (if you changed only the comments, not the actual code).

Vlad
  • 35,022
  • 6
  • 77
  • 199
  • I am changing source but only adding comments not changing the program. Do you have a solution for this case? – user502603 Nov 10 '10 at 01:31
  • Actually no, changing source file means recompilation :-( Make and other build tools are not so clever to understand that only the comments are changed. – Vlad Nov 10 '10 at 02:05
  • Extended the answer to cover your case :) – Vlad Nov 10 '10 at 02:37
  • 1
    I get your point, but I think the poster wants *build reproducibility*. Often, it doesn't normally matter that a compiler produces binary equivalent data. Some code sequences are logically equivalent. A compiler can pick one on Sunday and a different one on Monday; a randomly directed optimizer may do this, for instance searching a set of equivalence sequence based on optimal run time. The permutations of equivalent basic blocks can be huge. There is nothing to say a compiler must produce the same output. That is just a nice thing that a particular compiler **may** guarantee. – artless noise May 17 '13 at 15:09
  • 1
    @artless noise: here is [an article](http://blogs.msdn.com/b/ericlippert/archive/2012/05/31/past-performance-is-no-guarantee-of-future-results.aspx) on a connected issue. In principle, you are right, a compiler is not obliged to guarantee that the same source code produces the same compiled code, and actually needs to do some additional work to ensure that. – Vlad May 24 '13 at 14:29