6

I have 3 build machines. One running on windows 2000, one with XP SP3 and one with 64bit Windows Server 2008. And I have a native C++ project to build (I'm building with visual studio 2005 SP1). My goal is to build "exactly" the same dll's using these build machines.

By exactly I mean bit by bit (except build timestamp of course).

With win2k and winxp I'm getting identical dll's. But they differ from dll built with win2008 server. I've managed to get almost identical dll's, but there are some differences. After disassembling the files I found out that function order is not the same (3 functions are in different order).

Does anyone know what could be the reason for that?

And a side question: In vcbuild.exe I've found a switch /ORDER. Which takes function order file as input. Anyone knows how that file should look like?

sth
  • 222,467
  • 53
  • 283
  • 367
ppiotrowicz
  • 4,464
  • 3
  • 32
  • 46
  • Have you tried running VS in 32-bit compatibility mode (or whatever it is called)? – Makis Aug 03 '09 at 08:47
  • It has to run in 32-bit compat, there is no 64bit version of visual studio AFAIK – ppiotrowicz Aug 03 '09 at 08:54
  • 1
    1. Is the Server 2008 machine running a different CPU? (I have once seen a similar issue where an AMD machine produced slightly different output to INTEL - weird but true). 2. Have you checked the installed updates to see if anything in there has changed any VS components? – Andy J Buchanan Aug 03 '09 at 22:35
  • 1. Yes, those are different processors, but they are all intels. 2. I'm pretty sure i have the same updates, but just to be sure, i will reinstall win2008 today. Thanks for reply – ppiotrowicz Aug 04 '09 at 04:42

3 Answers3

7

You might think that compiling is purely deterministic (identical inputs give identical output, every time) but this need not be the case. For example, consider the optimiser - this is going to need some memory to work in, probably more for higher optimisation methods. If on one machine a memory allocation fails (because the machine has less memory) then the compiler could omit that specific optimisation, resulting in different code being emitted.

There are a lot of similar situations, so you may be putting a lot of effort into something that is not doable. Why do you need the DLLs to be bitwise identical, anyway?

  • With optimizations turned off (/Od switch) i have the same problem. Bitwise equality is crucial in this project (can't really discuss why, sorry). – ppiotrowicz Aug 03 '09 at 08:44
  • 2
    The optimisation thing was just an example - there are LOTS of things that might make the compiler produce different output. –  Aug 03 '09 at 08:48
0

Do you run the same version of the chain tool (compiler, linker, ...), included 32/64 bits difference?

AProgrammer
  • 51,233
  • 8
  • 91
  • 143
0

Is Windows Server 2008 the only machine running 64 bit? If it is, that could be your problem.

  • It might be, but dlls from 32bit systems are are almost identical. The only difference is that _3_ functions are in different order (and there are lots of functions in the project). Disasembled code is almost the same. – ppiotrowicz Aug 03 '09 at 08:39