Compiled executable is different every time

[m3nth]

This is a problem I have with Application Builder:

No two executables I generate are ever the same, even for identical source code files.


I've seen discussions on this a long time ago, how the Application Builder includes date and time information or something like that into the executable. Most of the time I guess it's not a problem and I've also resorted to using realtime checksum calculations to verify my files. What realtime checksum calculation doesn't get me however is being able to verify that I can build a certain executable file from a certain set of source code files--one of the major underpinnings of software configuration management.

Basically, every time it comes to using a LabVIEW program and doing a build verification, my software configuration management department has an impossible time and it really throws a wrench in the works. I'm looking for either a workaround for this, alternative method, setting in an INI file--anything like that--or a feature addition in the next Application Builder that will allow identical code code to be compiled into an identical executable. Configuration control issues like this that are virtually guaranteed in any C++ compiler make the people I work with not liking LabVIEW so much at all because it can't be independently verified that your source code is producing a certain version of the executable you want to use.

[Scott Y]

The slight differences you have been between the binary files is fundamental to the file format used by LabVIEW when creating the executables.

Knowledgebase 1P1H424U: The LabVIEW 5.1 Application Builder Produces Slightly Different Binary Files for Identical Source Code describes the reasons for this in more detail.

Scott Y.
NI

[m3nth]

That knowledgebase provides slightly more information than the original article that is also linked under that one. Interesting.

My thoughts are:

- If this is a 'feature' (wink wink 🙂 ), tally my vote to have an option to turn this off.

- If this is a bug, tally my vote to fix it.

I certainly know nothing about the internal workings of LabVIEW, but it can't be impossible to fix this. My stab at it would be to export the memory pointers and date/time information that are used the first time (all unique information) so they can be used a second time with the same files... I mean that sounds simple enough from the layperson's perspective.

All original source code + Unique first-time compile info = Second-time identical compiling capability.

[Scott Y]

If you would like to submit this suggestion so that it will be considered by our R&D department for a future release of LabVIEW there is a product suggestion link available at ni.com/contact

The link is labeled "feedback" and is under the "Product Feedback" heading.

Scott Y
NI

[GPeople]

I am having the exact same problem...our configuration management department is now demanding that we RETEST every tool entirely because we cannot

reproduce the original application checksums.

All the time saved by using LabVIEW is now going to be LOST every time we do a customer release (and possibly much more).

Our software tools (32 of them) are very complex have approximately 25 test procedures EACH that verify their functionality.

That's like 800 test procedures!!  Who has that kind of time and money??

I have been very impressed by this NI product until today.

If it is not possible to compile an exact replica of the executable that was created years ago...then there will always be that doubt that it all really works

the same no matter how much you test it. 

I guess if you are making non critical applications like operating bubble gum machines, this would be acceptable.

If anyone has a work around or a solution to this please let me know.  Thanks!

Very Disappointed,

-Ryan

[m3nth]

Ryan,

Your comment on this thread will not be noted by the majority of users since you are making a post on an old thread.  The people who have replied to this thread will receive an email notification (maybe), but that's about it.  It is usually recommended that you make a new thread and reference the older post if you want it to be noted, or to see if there are any updates since the old thread was posted.


Message Edited by m3nth on 03-17-2008 08:49 PM

[Karunya_R]

Hi Ryan,

I will put in your feedback as a product suggestion.

[GPeople]

Thanks!

I have done the same with the original post.

-Ryan

[dhedges]

I'm a member of the LabVIEW group, and I'm interested in learning more about what we can do here.  For instance, when Microsoft Visual Studio builds EXEs, they include a timestamp.  So you could make the argument that their EXEs are also not reproducible.  Is there some standard that you reference to flexibly determine if the EXE is an "exact replica"?

Also, what version of LabVIEW are you using?

--Dan


Message Edited by dhedges on 03-19-2008 02:14 PM

Message Edited by dhedges on 03-19-2008 02:20 PM

[m3nth]

I'm not sure what version I was using when I posted, and I haven't looked at the problem since then, but my guess would be that it hasn't changed in newer versions.

I am also unaware of Visual Studio producing any binary differences in the files when it builds them from source code--that's news to me.  Files get a new timestamp of course from the OS but for most languages the same source code will produce the same executable with no differences.

There are a number of tools which do binary comparisons. Beyond Compare and ExamDiff I believe are two of many.  Most of these tools add shell extensions to the windows right-click menu so you can easily select one file and then compare it to another.  You can also do a no frills binary comparison using the fc command in dos with the /B flag.  Don't expect it to be helpful if there are differences but you can easily verify if two files are the exact same or not.