Hi,
I have faced some situations when executables and shared libraries built from same code on different days differ in checksum.
They have the same size in most occasions.
In some cases the size is also different by a couple of bytes.
No change has been done to the system or the code.
What can be the reason?
Thanks
> But this happens for some only and not all.
If you're interested in what exactly is different, you can use debugging information dumping utility (dumpstabs for stabs format and dwarfdump for DWARF format).
For example:
[code]$ CC -g a.c
$ /opt/SUNWspro/bin/dumpstabs a.out > 1
$ CC -g a.c
$ /opt/SUNWspro/bin/dumpstabs a.out > 2
$ diff 1 2
326c326
<5: .stabs "V=9.0;DBG_GEN=5.0.8;dm;cd;backend;ptf;ptx;ptk;s;g;R=5.8<<Sun C++ 5.8 2005/10/13 (ccfe)>>;G=.XAB_pf0ZKZ6E2mO.;A=2",N_OPT,0x0,0x0,0x44e99299
>5: .stabs "V=9.0;DBG_GEN=5.0.8;dm;cd;backend;ptf;ptx;ptk;s;g;R=5.8<<Sun C++ 5.8 2005/10/13 (ccfe)>>;G=.XAB_pf0jKZ6EWoO.;A=2",N_OPT,0x0,0x0,0x44e992a3
370,371c370,371
<5: .stabs "V=9.0;DBG_GEN=5.0.8;dm;cd;backend;ptf;ptx;ptk;s;g;R=5.8<<Sun C++ 5.8 2005/10/13 (ccfe)>>;G=.XAB_pf0ZKZ6E2mO.;A=2",N_OPT,0x0,0x0,0x44e99299
<6: .stabs "/home/aaa/temp/; /opt/SUNWspro/prod/bin/CC -g -xs a.c -Qoption ccfe -prefix -Qoption ccfe .XAB_pf0ZKZ6E2mO.",N_CMDLINE,0x0,0x0,0x0
>5: .stabs "V=9.0;DBG_GEN=5.0.8;dm;cd;backend;ptf;ptx;ptk;s;g;R=5.8<<Sun C++ 5.8 2005/10/13 (ccfe)>>;G=.XAB_pf0jKZ6EWoO.;A=2",N_OPT,0x0,0x0,0x44e992a3
>6: .stabs "/home/aaa/temp/; /opt/SUNWspro/prod/bin/CC -g -xs a.c -Qoption ccfe -prefix -Qoption ccfe .XAB_pf0jKZ6EWoO.",N_CMDLINE,0x0,0x0,0x0
[/code]
I suppose those funny .XAB.... names are temp file names, and they *can* be identical.
> Any easy hint about what are there 2 formats: stabs & format
If you need more info on debugging information formats, you can find good brief article here: http://blogs.sun.com/roller/page/quenelle?entry=stabs_versus_dwarf
> I have tried stripping to get rid of the debugging information.
> Still the checksums are different.
Well, are you sure that your executable has no timestamp embedded? It is pretty common to build version and timestamp into an executable in order to have the ability to distinguish between two of them build from different code bases.
There are at least two things that can cause the same file to generate a different binary when recompiled using Sun C++.
One is the timestamp in the file. If you strip the file, the timestamp will be removed, along with other debug data. When we compare binaries in our group here at Sun, we strip copies, then compare the copies. That is, we care about the code generation being the same more than we care about meta-data being identical.
The second has to do with "globalizing" variables. When you compile for debug (-g or -g0), or use cross-file optimization (-xcrossfile or -xipo), static variables are promoted to global and get a hashed prefix on the name. Globalization allows fix-and-continue under the debugger, and allows the cross-file optimizer to keep track of static variables having the same name in different scopes. The hash protects against name collision.
The hash involves the path to the file being compiled, the block depth in the file, and the compilation timestamp. The timestamp is included to ensure correctness if the same source file is compiled more than once in the same program. Example:
CC -DONE foo.cc -o foo1.o
CC -DTWO foo.cc -o foo2.o
We have an undocumented Qoption in recent C++ compilers that eliminates the timestamp from the globalization hash.
CC -Qoption ccfe -xglobalstatic <rest of command line>
A Qoption in general is not stable, and could change meaning in or be removed from future compilers. We don't plan to remove this Qoption, but we might later provide a public, supported option.
