alg@cornell.UUCP (Anne Louise Gockel) (06/05/90)
I followed the proceedures for compiling gcc 1.37.1 on a DECsystem 3100 running UWS 2.2 / Ultrix 3.1. The procedures suggest that you build gcc once with the Ultrix cc compiler, a second time with the gcc compiler and a third time with the new gcc in order to compare the binaries. When I compared the binaries in the manner specified in Step 10) of the INSTALL document, I found that many of the files had differences beyond just the date stamp. The differences were extremely regular, almost as if there was a datestamp in the middle of the file. Has anyone run into this problem? Have I made a mistake in the installation procedure? Is there a good explanation for these differences? Thank you, Anne Louise Gockel Cornell Computer Science Internet: alg@cs.cornell.edu ---------- Partial list of differences from the "cmp -l" command, comparing the stage2 and the stage3 .o files: ---------- c-convert.o 4838 70 67 4839 61 64 4840 64 65 4841 60 67 c-decl.o 52282 70 67 52283 61 64 52284 62 64 52285 70 65 c-parse.tab.o 84669 70 67 84670 61 64 84671 62 63 84672 62 71 c-typeck.o 57886 70 67 57887 61 64 57888 63 65 57889 64 61 caller-save.o 4177 70 67 4178 63 67 4179 70 60 4180 65 62 cccp.o 90622 70 67 90623 64 70 90624 70 60 90625 71 67 cexp.o 12782 70 67 12783 64 70 12784 71 61 12785 65 63 combine.o 48006 70 67 48007 63 66 48008 64 66 48009 71 63 cse.o 52077 70 67 52078 63 66 52079 62 63 52080 62 71 dbxout.o emit-rtl.o 16013 70 67 16014 62 66 16015 70 60 16016 64 61
bogaart@serc.serc.nl (Eugene &) (06/05/90)
In article <41714@cornell.UUCP> alg@cornell.UUCP (Anne Louise Gockel) writes: The procedures suggest that you build gcc once with the Ultrix cc compiler, a second time with the gcc compiler and a third time with the new gcc in order to compare the binaries. When I compared the binaries in the manner specified in Step 10) of the INSTALL document, I found that many of the files had differences beyond just the date stamp. The differences were extremely regular, almost as if there was a datestamp in the middle of the file. Has anyone run into this problem? Have I made a mistake in the installation procedure? Is there a good explanation for these differences? Thank you, Anne Louise Gockel Cornell Computer Science Internet: alg@cs.cornell.edu ---------- Partial list of differences from the "cmp -l" command, comparing the stage2 and the stage3 .o files: ---------- c-convert.o 4838 70 67 4839 61 64 4840 64 65 4841 60 67 c-decl.o 52282 70 67 52283 61 64 etc... I had the same problem with gcc 1.36, but I looked a bit further and found that the so called differences are: diff ../testdiff/c-convert.o.hexl ./c-convert.o.hexl 1c1 < 00000000: 6201 0300 0eec 5826 3412 0000 6000 0000 b.....X&4...`... --- > 00000000: 6201 0300 9df8 5726 3412 0000 6000 0000 b.....W&4...`... 405c405 < 00001940: 722f 746d 702f 6363 6130 3635 3130 2e73 r/tmp/cca06510.s --- > 00001940: 722f 746d 702f 6363 6130 3334 3339 2e73 r/tmp/cca03439.s According to me this is harmless, because they don't differ a lot ! The above output of a special diff shows that the first lines differ and that half way the file is another difference. I have tested it, and it appears to be in every *.o file. It is, I think, the name of the intermediate assembler file where the *.o file is generated from (but this is a guess !). Further I did not experience many problems in using gcc (1.36) on the DEC Stations, but I did not use it extensively. Eugene -- Name: Eugene Bogaart | Software Engineering Research Centre Email: bogaart@serc.nl | Lange Viestraat 365 3511 BK Utrecht Phone: +31 30 32 26 40 | P.box 424 3500 AK Utrecht Fax: +31 30 34 12 49 | The Netherlands
teege@lan.informatik.tu-muenchen.dbp.de (Gunnar Teege) (06/05/90)
In article <41714@cornell.UUCP> alg@cs.cornell.edu (Anne Louise Gockel) writes: > >I followed the proceedures for compiling gcc 1.37.1 on a DECsystem 3100 >running UWS 2.2 / Ultrix 3.1. >... in Step 10) of the INSTALL document, I found that many of the files had >differences beyond just the date stamp. The differences were extremely I had the same problem. <bogaart@serc.nl> gave me the right tip: the files all differ in the COFF-timestamp (as written in the INSTALL file) and somewhere half way down, where they contain the name of the intermediate file used by the compiler when they were generated (funny - of course these names are different). I checked my files: All other parts are identical. Does anyone know why these file names are included into the o-files and which part is doing that? Perhaps this could be eliminated. At least there should be inserted a hint in the INSTALL document like that for the COFF timestamp. Gunnar Teege Inst. fuer Informatik, Technische Universitaet Muenchen PO-Box 202420, 8000 Muenchen 2, West-Germany teege@lan.informatik.tu-muenchen.dbp.de +49 89 2105 8179 teege%lan.informatik.tu-muenchen.dbp.de@{unido.uucp,relay.cs.net,unido.bitnet}
meissner@osf.org (Michael Meissner) (06/06/90)
In article <2635@tuminfo1.lan.informatik.tu-muenchen.dbp.de> teege@lan.informatik.tu-muenchen.dbp.de (Gunnar Teege) writes: | In article <41714@cornell.UUCP> alg@cs.cornell.edu (Anne Louise Gockel) writes: | > | >I followed the proceedures for compiling gcc 1.37.1 on a DECsystem 3100 | >running UWS 2.2 / Ultrix 3.1. | >... in Step 10) of the INSTALL document, I found that many of the files had | >differences beyond just the date stamp. The differences were extremely | | I had the same problem. | <bogaart@serc.nl> gave me the right tip: the files all differ in the | COFF-timestamp (as written in the INSTALL file) and somewhere half way | down, where they contain the name of the intermediate file used by the | compiler when they were generated (funny - of course these names are | different). I checked my files: All other parts are identical. | | Does anyone know why these file names are included into the o-files | and which part is doing that? | | Perhaps this could be eliminated. At least there should be inserted | a hint in the INSTALL document like that for the COFF timestamp. I replied to the original article in the proper newsgroup of gnu.gcc.bug rather than the inappropriate group of gnu.gcc. The short answer is yes, the assembler is putting the intermediate filename in the object file's file table, and the patches I just sent to the FSF fix this through a kludge. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA Catproof is an oxymoron, Childproof is nearly so
frank@croton.enet.dec.com (Frank Wortner) (06/11/90)
As I remember it, there is a script called "ecoff-cmp" in the top level directory of the GCC distribution. It strips out the headers and compares only the instructions and data in the executable file. This has worked just fine the times I've tried it. Regards, Frank