LabVIEW built applications should be identical

[R_Beauchaine]

When building the same application multiple times, a binary comparison reveals differences between the supposedly identical exe's. This is problematic from a Configuration Management standpoint. We are required to show we can replicate the build at any time, but the only way to prove it is the same is via binary compare.

[dthor]

I don't know the details, but perhaps the dierence is a timestamp somewhere in the binary? Is that something you can claim to your employer, that the difference is caused by a timestamp or perhaps other details (current logged in user, OS Version, etc.)?

[AristosQueue (NI)]

No one has reported this issue before to the best of my knowledge, but knowing what I know about compliance officers, I imagine this is a significant problem for you.

I have filed a CAR (#351957) to investigate this, but I am *not* suggesting that this idea be closed at this time, the way we usually do with ideas that are bug reports. I say that because it will depend upon what feature is found to be causing the issue. If it is all EXEs, that is more of a bug to me. If it is only EXEs that use a particular feature, then it may be that the feature is behaving as designed and it might be worth researching a different implementation of the feature, but only if this idea were to get sufficient kudos. I'm not sure at this time, so I figure it's worth leaving the idea open for now. 

We're right in the middle of finalizing LV 2012, and so it may be a while before anyone gets around to investigating this further. If you do manage to isolate exactly a single LV feature that causes this behavior in EXEs, please contact an NI application engineer (either by phone or the regular forums) and give them the CAR number. Thanks.

[GregR]

My esteemed colleague simply didn't have the knowledge. This has been discussed at length (perhaps not publicly). There is in fact a timestamp in the windows executable format (PE). This is inserted by the linker, so every time a windows executable is built (from LabVIEW or any other environment) the binary will be different. In the past there have also been other things that changed inside the binary but I believe we eliminated the others. At this point resaving a VI with no changes should produce the same file.

When faced with this issue, I believe some people have developed their own comparison tool that ignores this timestamp. You could also create something that overwrites the timestamp with a more repeatable value (ex. the timestamp of some significant file in your source control system).

[AristosQueue (NI)]

Thanks, Greg.

[Lavezza]

In a 180kb exe I'm seeing ~6kb in differences. Much more than a timestamp. These were built about 60 seconds apart.

24 pages of this:

[GregR]

The linker timestamp is somewhat out of our control. The way we put the individual VIs into the application file also records a timestamp for each VI. The last time we researched this, I believe we got it down to just a few issues like this. It is also fairly likely that new issues have been introduced since that time. In the end the people we were working with before decided to go with an approach of verifying the files used in the build, rather than a binary comparison of the output.

[jamesbe]

I am running into this issue at work right now. Did anyone find a work-around?