#1
  1. No Profile Picture
    Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2003
    Posts
    5
    Rep Power
    0

    Same build, different checksums ??


    Hi,

    I am using gcc v2.96 on Linux to compile, and some of my resulting .o files have a different checksum every time. Here is an ascii dump diff of two of the same .o files, built within minutes of each other on the same machine, but have different checksums. I have included +- 8 lines of context with the diff:

    00084A80: 70).__tiQ24_STL1
    00084A90: 1logic_error:G(0
    00084AA0: ,70).__tiQ24_STL
    00084AB0: 13runtime_error:
    00084AC0: G(0,70).__tiQ24_
    00084AD0: STL17__Named_exc
    00084AE0: eption:G(0,70)._
    00084AF0: GLOBAL_.I.Reques
    -00084B00: tQueue.cppqwuz2c
    +00084B00: tQueue.cppLWW03b
    00084B10: :f(0,21).Request
    00084B20: Block.cpp.__10Da
    00084B30: ta_BlockP11Reque
    00084B40: stBaseP13New_All
    00084B50: ocator:F(0,25)=*
    00084B60: (0,26)=xsData_Bl
    00084B70: ock:._data:p(0,2
    00084B80: 7)=*(0,28)=xsReq

    As you can see, its the "cppqwuz2c" line that changes to "cppLWW03b" that's causing the checksum change. If I run the build again, it will be some new "cpp<randomtext>" sequence of characters to throw off the checksum again.

    Does anyone know what can be causing this or seen something like it before? This is happening in just several of my .o files across a project with hundreds of .o's whose checksums are the same every time, so the compiler is probably working right.

    Thanks a great deal in advance for any help!
    --Brian E. Bianchi
  2. #2
  3. Left due to despotic ad-min
    Devshed Beginner (1000 - 1499 posts)

    Join Date
    Jun 2003
    Posts
    1,044
    Rep Power
    14
    I'd guess that the code being compiled uses the __TIME__ and/or __DATE__ predefined macros. Those macros expand to a string that contains the compile time and date respectively.

    On some systems, the object file format is actually required to contain a time stamp. IIRC, that's not the case with gcc under Linux, but that's another possible explanation of the behaviour you're seeing.
  4. #3
  5. No Profile Picture
    Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2003
    Posts
    5
    Rep Power
    0
    Thanks for you response, but I still don't get it. Where are the __TIME__ and __DATE__ values you quote coming from? Why does this happen with only just a few object files out of a hundred or so that make up my project's build?

    How would I go about stopping this from happening so I can get a consistent checksum? Is the problem in the code somewhere, or the compiler?

    Thanks again
    --B
  6. #4
  7. No Profile Picture
    Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2003
    Posts
    14
    Rep Power
    0
    I thought it might be one of these macros as well... but looking at the code, it doesn't look like it. I would suggest reading through the ELF binary format... and look for variable values, like build times, etc. The macros mentioned __FILE__ simply are in the code, and just like any macro, are replaced by the preprocessor.
  8. #5
  9. No Profile Picture
    Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2003
    Posts
    14
    Rep Power
    0
    As I see it... if you got the same checksum across builds, that would defeat the point of the checksum in the first place. Being able to release a build and say, here is the checksum, allows people to verify that someone else didn't come around and build it again... etc.
  10. #6
  11. No Profile Picture
    Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2003
    Posts
    5
    Rep Power
    0
    My bosses want two equal builds to result in two equal checksums. And when it doesn't happen, they want to know why :-(
  12. #7
  13. No Profile Picture
    Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2003
    Posts
    14
    Rep Power
    0
    Do a g++ -E twice and do a diff on the output... that will at least rule out the preprocessor.
  14. #8
  15. No Profile Picture
    Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2003
    Posts
    5
    Rep Power
    0
    I did as you suggested and the output from the g++ -E is the same in consecutive builds. The checksums of two object files from consecutive builds that results when I don't use the -E, are not :-(

    So I have ruled out the preprocessor. Thanks a great deal for that suggestion. Are there any other possibilities I might look into?

    I'm at wits end on this one.

    Thanks!
    --Brian
  16. #9
  17. No Profile Picture
    Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2003
    Posts
    5
    Rep Power
    0

    Getting somewhere


    I ran gcc with a "-v" and came up with something interesting. I am including the output below, although 99% of it is probably useless info. What is important, is the very last line, where a file in /tmp is referenced.



    gcc -v -c -g -D CT_LINUX -D linux -D LINUX -pthread -D _STLP_NO_OWN_IOSTREAMS=1 -D _PTHREADS=1 -D USING_STLPORT -D_STLP_USE_NEWALLOC -D_STLP_USE_MALLOC -DSR_DEBUG -DNOTICE -DSETS -DEMANATE -DSUBAGENT -DLINUX -DMIBDEFS=\"SpdTrapsdefs.h\" -DMIBPART=\"SpdTrapspart.h\" -DMIBSUPP=\"SpdTrapssupp.h\" -DMIBTYPE=\"SpdTrapstype.h\" -DMIBOID=\"SpdTrapsoid.c\" -DSR_UDS_IPC -DSR_TRANSPORT_TABLE -DSR_SNMPv2c_PACKET -DSR_SNMPv1_WRAPPER -DSR_SNMPv2_PDU -DSR_NOTIFY_FULL_COMPLIANCE -DSR_SNMP_ADMIN_MIB -DSR_GENERATE_CONFIGURATION -DSR_MIB_TABLE_HASHING -DSR_CONFIG_FP -DSR_IP -I ../../../BaseSvcs/../cakits/STLport/stlport -I ../../../BaseSvcs/../cakits/ACE/ACE_wrappers -I ../../../BaseSvcs/../BaseSvcs/export/include -I ../../../BaseSvcs/../BaseSvcs/export/include/smap -I ../../../BaseSvcs/../OMAP/export/include -I ../../../BaseSvcs/../OMAP/code/LNXAlarmSubAgent -I ../../../BaseSvcs/../ThirdParty/emanate/snmp15.4.1.2/include -I ../../../BaseSvcs/../cakits/inflection-components/Util/include -I ../../../BaseSvcs/../cakits/inflection-components/Interfaces/include -fPIC SpdTrapsoid.c
    Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
    gcc version 2.96 20000731 (Red Hat Linux 7.2 2.96-112.7.2)
    /usr/lib/gcc-lib/i386-redhat-linux/2.96/cpp0 -lang-c -v -I ../../../BaseSvcs/../cakits/STLport/stlport -I ../../../BaseSvcs/../cakits/ACE/ACE_wrappers -I ../../../BaseSvcs/../BaseSvcs/export/include -I ../../../BaseSvcs/../BaseSvcs/export/include/smap -I ../../../BaseSvcs/../OMAP/export/include -I ../../../BaseSvcs/../OMAP/code/LNXAlarmSubAgent -I ../../../BaseSvcs/../ThirdParty/emanate/snmp15.4.1.2/include -I ../../../BaseSvcs/../cakits/inflection-components/Util/include -I ../../../BaseSvcs/../cakits/inflection-components/Interfaces/include -D__GNUC__=2 -D__GNUC_MINOR__=96 -D__GNUC_PATCHLEVEL__=0 -D__ELF__ -Dunix -Dlinux -D__ELF__ -D__unix__ -D__linux__ -D__unix -D__linux -Asystem(posix) -D__NO_INLINE__ -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -D__tune_i386__ -D__PIC__ -D__pic__ -D_REENTRANT -D CT_LINUX -D linux -D LINUX -D _STLP_NO_OWN_IOSTREAMS=1 -D _PTHREADS=1 -D USING_STLPORT -D_STLP_USE_NEWALLOC -D_STLP_USE_MALLOC -DSR_DEBUG -DNOTICE -DSETS -DEMANATE -DSUBAGENT -DLINUX -DMIBDEFS="SpdTrapsdefs.h" -DMIBPART="SpdTrapspart.h" -DMIBSUPP="SpdTrapssupp.h" -DMIBTYPE="SpdTrapstype.h" -DMIBOID="SpdTrapsoid.c" -DSR_UDS_IPC -DSR_TRANSPORT_TABLE -DSR_SNMPv2c_PACKET -DSR_SNMPv1_WRAPPER -DSR_SNMPv2_PDU -DSR_NOTIFY_FULL_COMPLIANCE -DSR_SNMP_ADMIN_MIB -DSR_GENERATE_CONFIGURATION -DSR_MIB_TABLE_HASHING -DSR_CONFIG_FP -DSR_IP SpdTrapsoid.c /tmp/ccAdFk8L.i



    The "/tmp/ccAdFk8L.i" reference actually is embedded in the .o file that results from this build, causing the checksum to be different every time. Here is an except:

    00000160: d........ccAdFk8
    00000170: L.i./vob/OMAP/co
    00000180: de/LNXAlarmSubAg
    00000190: ent/./tmp/ccAdFk
    000001A0: 8L.i.gcc2_compil
    000001B0: ed..int:t(0,1)=r
    000001C0: (0,1);-214748364
    000001D0: 8;2147483647;.ch


    Next time I run the build, the /tmp file will be different. What is generating that /tmp/ccAdFk8L.i file and why is it embedded in the object file? Any help?

    Thanks again!
    --Brian
  18. #10
  19. No Profile Picture
    Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2003
    Posts
    14
    Rep Power
    0
    The /tmp/*.i file is the resulting preprocessor file. You should be able to do a two step compilation, make the .i file yourself with whatever name you want. I'm using gcc 2.95.1 and it doesn't seem to include the TMPDIR files in the symbol table... you may want to find a compiler newsgroup and ask them what a better solution would be.

    I have to take care of something... but I'll see what I can find in a bit.

IMN logo majestic logo threadwatch logo seochat tools logo