Identical source codes and commands produce different binaries! WHY?

[woshiwuxin]

I compiled the module with the following commands:

[bash]/tmp/xwu> cat tools.f90 
module tools
  implicit none
  integer::i,j
end module tools
/tmp/xwu> ifort -c tools.f90 
/tmp/xwu> mv tools.mod 1.mod
/tmp/xwu> md5sum 1.mod 
cbef55676124885920c5e119ff3e4ea7  1.mod
/tmp/xwu> ifort -c tools.f90 
/tmp/xwu> mv tools.mod 2.mod
/tmp/xwu> md5sum 2.mod 
e833dfab17f60f8930db8b799b9bd5d2  2.mod
/tmp/xwu> diff 1.mod 2.mod 
Files 1.mod and 2.mod differ
/tmp/xwu> 
[/bash]

Moreover, take a prototypical "hello" program for example:

[plain][mcxwu:/tmp] xwu% cat hello.f90
program ex
  implicit none
  print *, "hello"
  stop
end
[mcxwu:/tmp] xwu% ifort -o 1.out -g hello.f90
[mcxwu:/tmp] xwu% ifort -o 2.out -g hello.f90
[mcxwu:/tmp] xwu% diff 1.out 2.out 
Binary files 1.out and 2.out differ
[mcxwu:/tmp] xwu% md5 1.out 2.out 
MD5 (1.out) = 12ca1ad83d739b247523521faf50cbe9
MD5 (2.out) = 496c0127a6e75b6e7b5f3249447e7d0c
[mcxwu:/tmp] xwu% 
[/plain]

The second example only happens on my Mac, but not on Debian. I'm just curious about this seemingly strange stuff.

BTW: for this "hello" example, both executables produce the identical "hello".

Thanks in advance!

[Hirchert__Kurt_W]

If I were in your shoes, I would first use "ls -l" to verify that the files are the same size. Assuming they are, I would then use diff to see how much of their content is different. (If I needed extra help in interpreting the nature of the differences, I might first od the two files with appropriate options and then diff the output from the two executions of od.)

My guess is that there will be only a few bytes of difference. When I have seen this kind of difference on other systems, it has typically been the result of some kind of time/date stamp embedded in the binary, often an indication of when the source file was compiled, but you will have to check for yourself whether that is what is happening in your case.

-Kurt

[woshiwuxin]

Thanks!

Because some other compilers produce the identical binaries or visible text files for modules. I'm just a little bit puzzled when I observed ifort produced seemingly different binaries.

od is very new to me. I've googled od. However, I've not quite understand this unix utility. It seems that those kinds of knowledge are relevant to some internals of computers.

[Ron_Green]

the header information includes the name of the executable and a timestamp. Even compiling the same source to same executable will cause different check sums.

ron

[woshiwuxin]

Thanks Ronald!

[Hirchert__Kurt_W]

Quoting woshiwuxin

od is very new to me. I've googled od. However, I've not quite understand this unix utility. It seems that those kinds of knowledge are relevant to some internals of computers.

For documentation on commands on your machine, I would encourage you to start with the man command (in this case "man od") to get documentation specific to the version of those commands running on your machine. Unless you are very careful, using Google is likely to get you information on versions of those commands that run on some other kind of system. Such descriptions are likely to be generally similar to what you have, but may differ in important details (e.g., describe a feature that isn't implemented in the version you have).

Since Ron has already confirmed that ifort includes timestamps, you probably don't need to mess with od this time. For what its worth, "od" stands for "octal dump" -- by default, it creates an octal listing of the contents of a binary file. However, you can use options to cause the listing to be in another format. (For example, I like to use "od -c -tx1" to get each byte of the file listed both as a character and in hexadecimal.) If you have no knowledge of computer internals, an octal or hexadecimal dump of your file may not tell you anything very useful and you may not find od to be a valuable tool for you.

-Kurt