Is there a way to control the 'time date stamp' which the Microsoft VC++ 6.0 compiler and linker put into object files and EXE/DLL files?
I have a relatively large project, comprising about 1000 source files, mostly JAVA and TEXT files, but a small number of Windows C/C++ sources.
The build process is automated using ANT, and produces jar files, war files and eventually exe files using NSIS.
I keep all the sources under version control using Subversion.
What I want to do is verify the MD5 checksum of the final build product, so I can have absolute confidence that a particular EXE was built from a particular set of checked out sources.
This mechanism works great for anything not using Microsoft tools.
For JAR and WAR files, all you have to do is TOUCH the individual components before packaging, (to force a predefined Build timestamp), and the MD5 of the JAR/WAR will be stable.
For NSIS EXE files, the same applies. If you TOUCH the component files, before running the .nsi script, the MD5 of the final product will be repeatable. The same is true for ZIP files and similar.
But for the Microsoft C++ source files, which are compiled using CL.EXE and linked using LINK.EXE, I cannot find how to force the compile timestamp and link timestamp to have a particular value.
Instead, the tools always use current time.
Microsoft embeds these timestamps into the COFF object and EXE/DLL files, so the object files are always slightly different on each build, and this makes the MD5 signature of the EXE/DLL (or any archive with such a file as a subcomponent) different.
This makes checking the resulting MD5 useless for confirming that a particular set of sources generates a particular release version of the deliverable.
Does anyone know how to get around this?
I was expecting some command line switch or environment variable settings or something like that which would cause the designated time to be used instead of current time.
The toolchain is Microsoft Visual Studio 6.0 Professional (the latest and greatest before .NET)
I have spent a lot of time experimenting in the past with workarounds, and getting really frustrated
I really would like to avoid having to keep copies of large binary files just to make my ZIP/WAR/NSIS files stable.