2

I am trying to ensure that two different machines produce identical builds. I have tried to make the environment as similar as possible but I still see some differences in the generated .obj and .exe files. I have been able to rule out embedded path differences and timestamps. I have also ensured that minimal code examples (like a hello world program in fact produce identical binaries).

Currently some object files are similar while others are not. If I look at the ones that differ using a diff of dumpbin /all I see differences like this:

> COMDAT; sym= "public: static int const std::numeric_limits<long double>::max_exponent" (?max_exponent@?$numeric_limits@O@std@@2HB)

< COMDAT; sym= "public: static int const std::_Locbase<int>::collate" (?collate@?$_Locbase@H@std@@2HB)

in many of the SECTION HEADER. Without having proved it 100% it seem to me that each difference is a line that occurs in another section in the dumped output from the other object file. So things seem to be in a different order. (But note that it's only my current assumption - I might be wrong.)

Any hints on how to move on from here and what the cause might be ? Build / link order ?

I have also seen that Microsoft writes this:

NOTE: There is no guarantee that Visual C++ will generate the same binary image when building the same source files on successive builds. However, you are guaranteed that the EXE (or DLL) will behave in precisely the same manner under execution, all other things being equal.

but I am still wondering what is happening in my specific case. In my case consecutive builds on the same machine provide identical builds.

Zitrax
  • 19,036
  • 20
  • 88
  • 110
  • It is unlikely to ever get identical binaries from different machines (or from the same machine even). Unless you specifically state, which parts should be identical (and what you are going to do with this information), this question can only be answered with: Not possible. – IInspectable Dec 15 '15 at 11:17
  • @IInspectable - For me it would be enough to prove it for a single build pair - I do not need continuous binary matches. But in general is this a problem that is much harder to solve in Windows than Linux ? Limitations in VS ? I have seen several cases around where work has been progressing on build reproducibility on Linux - for example the debian packages. – Zitrax Dec 15 '15 at 11:28
  • As you quoted already, Visual Studio guarantees identical behavior, and that's it. You still haven't explained, why you need to know, whether 2 binaries are identical (for some definition of *identical*). Without knowing, why you need this information, it's hard to provide a satisfactory answer. – IInspectable Dec 15 '15 at 11:32
  • @IInspectable - It's a security requirement, (similar to what was done in the TrueCrypt audit). If there are differences I should at least be able to find out why. And in the case I showed above I still have no satisfactory answer. For smaller programs I have been able to pinpoint that the difference A is due to X and difference B is due to Y. – Zitrax Dec 15 '15 at 12:20
  • Did you try the steps recommended in the knowledge base article you linked to (specifically, using DUMPBIN with the /RAWDATA switch), even though they likely apply to a compiler you aren't using? – IInspectable Dec 15 '15 at 13:12
  • @IInspectable yes that's included in the /ALL switch I used - so it's basically the same as what I posted above. The raw value in that case say it changed from 00040000 to 01000000 which does not tell me much. – Zitrax Dec 15 '15 at 13:18
  • Ok, I wasn't aware of this. If this doesn't produce a reliable solution you may have more success comparing the .obj files instead of the final binary image. – IInspectable Dec 15 '15 at 13:35
  • It's the object files that I am comparing now as mentioned in the question text. – Zitrax Dec 15 '15 at 13:44

1 Answers1

2

So even though I can't explain exactly why the binary looked like it did I found one "unexpected" difference in the environment which was the root cause.

The build log mentioned different versions for rc.exe (the resource compiler). It turns out that it's part of the Windows Kits which come with VS. However if you install two versions of visual studio they will share rc while the compiler and linker are separate.

After making sure to install the other VS that I did not compile with the binary changed to match what I would expect.

Zitrax
  • 19,036
  • 20
  • 88
  • 110