how to re-compile a project with the same results of old compilation

a very strange question, if I may comment. why do you care abut the exact layout of the binary? don't you care more about the functional value of the binary? is there something else we need to know...?

I need the content of the "old" hex file because it was burned into a ROM.
This code can not be changed.
I want to run tests on a version that is exactly the same to the version that is burned into a ROM.
Noam
--------------

but why? if your C code has not changed, and the build tools have not changed, unless there is a bug in the build tools - both binaries must function in the exact same way.

Many companies have a policy that they must be able to later reproduce an _exact_ copy of an already released binary. The rule is actually quite sound, since it not only makes sure that you have perfect control over your build environment, but also that you can - at a later time - do an analysis on code already released.

The tools should normally produce the identical results, as long as no __DATE__ och __TIME__ defines have been used.

It is a bit strange that the Keil tools throws the layout around.

I want to run tests on a version that is exactly the same to the version that is burned into a ROM.

So what's keeping you from running those tests with the actual .hex file you burn into those ROMs?

Anyone knows why the compilation has changed (though the C files have not changed)?

No. You've stated several things you didn't change --- but there are quite a number of others that you didn't say anything about. Without that knowledge, nobody can know why things changed. At best we can mare more-or-less wild guesses.

Did you keep all the compiler and linker settings the same? Is it the same version of the compiler?

And what, actually, are those "etc." things that changed?

Were the files compiled from a make file or the IDE. The build options and the linker settings must be exact to get the same hex file. Also the compiler version must be the exact same (assuming a different computer) including any updates. Finally, again assuming a different computer, did the original programmer modify (or have a stash of modified) startup.A51, putchar.c or getchar.c

We finally managed to find the problem.
it was a different option (Opt).
Thanks all

there is one case where the "exact same" does not produce identical results.
I redid a piece of inherited code to make it adhere to the company coding standards and tried to match and it did not.
the "exact same" code does not produce the "exact same" .hex if you change variable names.

Erik

Unless any tool sorts the variables on name, the final output really should be the same - as long as "final output" is defined as a file format that doesn't contain debug information.

the "exact same" code does not produce the "exact same" .hex if you change variable names.

Depends on how you read "exact same".

To me (and certainly in our dev team), it must be 'the same as when originally created'; i.e., same source files, same configuration files, same compiler environment. An archive of the project is created at time of release.

The worst offender I know for such un-reproducability is Delphi. Build the project, take a copy of the file, rebuild, compare, see lots of differences.

With Keil C51, I've never seen such a problem.

This is why I prefer to ensure that a build batch file can be generated from the IDE settings. Then when you release a 'final' version, you can rebuild it with the archived source, along with the compiler, assembly, and linker executables.

Being able to reproduce the code, exactly, should be a priority when building executable code: especially if a ROM is going to be burned.

Although the IDE does save these configuration settings, a version change to the IDE can alter the output. Just like a revision to the command line executables can also cause an altered output.

But at least when you archive the build batch files and the command-line .EXE files, you won't need a full install of the IDE in order to re-create the exact output.

In order to do this, you must build the application [in a separate directory or even on a separate computer] with the items you officially archived, and use that output to do your formal qualification testing prior to release. It may sound like a hassle, but you will need to weigh the costs of an error in the field with this relatively minor effort.

As Mr. Westermark points out, things like __DATE__ and __TIME__ need special attention and consideration when using them.

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

I normally create a revision string using the source code repository tools instead of using __DATE__ and __TIME in the file.

When the application boots, it will not present the time of compilation, but the time when a "version.h" file was committed. That makes sure that the version numbering and the time stamp belong together.

Best is when all production code can always be automatically checked out and built on a dedicated build machine. Howver, that is seldom possible for commercial tools since they normally require one license/machine, and does not allow multiple users to access the same installation.

But an even worse problem that is starting to crop up is that more and more companies rewrites their software licenses, requiring that after an update, the previous version of the application must be uninstalled and never, ever used again after maybe 7-30 days of overlap while validating that the new version is working.

I think the software industry is trying to dig its own grave by constantly creating more and more ridiculous licenses. Some licenses may even require several hours to read - if anyone actually bothers... My faviourite is the USB thumb drive - marketed for transfer of files between different computers, but with a license requiring that it is only used on one (1) computer.

I just hope that Keil and the other tool vendors realizes that when the license texts gets too strange, we will not just ignore the strangest parts of the licenses - we will ignore every single line of them. Or the product.

Many software companies seems to miss that the harder licenses they have, the more inclined their customers are to switch to alternative products, even if the alternative product may not be as good. A practically working solution always wins over a "perfect" tool that can't be used.

I just hope that ... tool vendors realizes that when the license texts gets too strange, we will not just ignore the strangest parts of the licenses - we will ignore every single line of them. Or the product.

I appreciate the vendors need to protect their software from piracy, but sometimes they seem to protect the legal, lawful owner of their software from 'pirating' what they already legally, lawfully own.

does anybody remember the old beautiful "book licence" (treat it as a book, only one can use at a time)

Well, once more thieves (no other word fits) makes it more difficult for normal honest people (no thieves, no need to lock the door) and we, probably have only two choices
a) shoot the thieves.
b) live with crummy protection schemes.

Erik

BTW I just realized I could have writtent just about the same thet I wrote about the thieves about the idiots that think it is fun to make vira, worms etc and force us to have out computers spend half the time to protect us and only half the time doing useful work.

shoot the thieves

?!

in Texas, they allow teachers to carry guns. I wonder if you support the same privilege for software engineers as well?