7
votes

In a fresh VCL application Compile and Build operation produce the same binary and map file (with minor differences at the end of .exe file even if "include version information in project" option is switched off - already discussed). Map file is the same byte to byte. But wen I add any third-party component the binary and map(!) file produced by Build and Compile are significantly different!

Tested on two versions of Delphi:
- Version 7.0 (Build 8.1)
- CodeGear™ RAD Studio 2007 Version 11.0.2902.10471 (+December 2007 Update)

Step to reproduce:

  1. Create New VCL Application. Possibly add any native Delphi component (I try all components from Standart, Additional, Win32 and System tab).
  2. Turn on Detailed Map file on Linker tab of the Project Options.
  3. Build project.
  4. Rename output .exe and .map file (for example: project1.exe to project1b.exe and project1.map to project1b.map).
  5. Compile project.
  6. Rename output .exe and .map file (for example: project1.exe to project1c.exe and project1.map to project1c.map).
  7. Compare files from step 4 and 6. (I use WinMerge 2.12.4.0).

We have little different .exe files and fully identical .map files. Then if we repeat all steps again but use in the project third-party component (I try ODAC, DOA, DevExpress and selfmade) we get more different .exe and different .map files.

Why? Any suggestions?

UPDATE
Some information about how I found this and why it's interests me:
Project is build from simple script with MSBuild. When in the project was added translation thru ITE (dll with resources) I found that when project was Build (from script or from IDE) - translated version work wrong - some text on button, labels etc. got from wrong place (literally from another button, labels). When project Compiled from IDE - everything is ok. So I start compare Build and Compile output...

3
No idea, but start your tests with simpler 3rd party components, and only then go to more complicated ones. Also make sure the sources remain 100% the same. Different USES clauses (including order!) might change the layout of unit initalization tables, and thus the binary.Marco van de Voort
Sources remain 100% the same - I only do build and compile.user244027
You'll also find that Build and Build produce different binaries. It has nothing to do with the difference between compiling and building.Rob Kennedy
@Rob: What do you mean that Build and Build produce different binaries? Do you mean Compile and Build?Vivian Mills
No, Ryan. Max said that if you build and then compile, you'll get different results. But if you build and then build again, you'll still get different results. The difference between compiling and building is irrelevant in this case.Rob Kennedy

3 Answers

12
votes

What you're seeing is simply an artifact of the built-in make logic of the compiler. When you do a build, it tells the compiler to build all available sources. So Delphi processes each source file and for each unit in the uses lists for which it finds source, it will then build that file. It does this recursively. When you do a compile, only the existing .dcu files are loaded and if they're found to be up-to-date, nothing is done. This can actually lead to a different order in which the units are discovered since each .dcu will effectively "flatten" the uses list. Since the units are discovered and loaded in a different order, they are in-turn, linked in a different order. This is why your map files look so different. Given the same sources, the map file should be the same if you do two builds in a row or two compiles in a row.

Other causes for differences are more mundane and include things like the PE header time stamp, and other bits of padding and alignments.

3
votes

There is two parts to this answer I believe.

Part of the problem your seeing, IIRC, is that the compiler doesn't zero out memory before doing a compile/build. Thus anything left in uninitialized memory becomes filler in the output for alignment purposes.

I also seem to recall that there is a date time stamp included in the pe header information for the application. that will cause a difference every time.

I'm not the best person to confirm this but this is what I seem to recall from past discussions.

People like Allen Bauer or Barry Kelly would probably be able to give better/more accurate information on this.

0
votes

If you use compiler defines in your project and just changed those, if you do a compile, you won't see any changes to the dcu's and the resulting module (exe or dll). If you do a full rebuild the compiler defines are used in the newly created dcu's and modules.

I have seen this in a large project group where we use modules in different projects with different defines and all dcu's are stored in the same directory.

Ergo: The compiler does not enforce the dependancies on the defines in this case.

Perhaps you did see the same issue.