> On 03/02/10 12:51, James Carlson wrote: >> Garrett D'Amore wrote: >>> Those tags were originally expanded by teamware/SCCS. With mercurial, >>> they are useless as they contain the original patterns rather than the >>> expanded forms. We've been removing them from source code as we update >>> it. >> >> To answer the next question: we haven't looked for a replacement because >> the version of the binary is more naturally reported (along with other >> important attributes) by the packaging system, assuming you don't have >> vandals on your system. >> >> This issue has been discussed several times. I think the most recent >> discussion may have been over on on-discuss. >> >> As for versions of header files used to compile a given binary, I can't >> say I've ever found much use in this, but if we did have to record >> something there, I'd prefer to have some clear indication of which >> package versions were installed on the system at the time of compilation >> rather than which per-file versions were there. The package version >> information tells me more, and makes figuring out dependencies easier. >> >> Of course, that leaves folks doing weird things with system header files >> and libraries from an alien version of the OS using -I and -L out in the >> cold, as well as the aforementioned vandals wielding "cp" across >> separately managed systems, but they probably have other problems as >> well. >> > > Future versions of packages will include mercurial changeset IDs as part > of package metadata; this makes things much simpler. In addition, > remember that any hash can be searched for using pkg(5): > : ba...@cyber[5]; digest -a sha1 /usr/bin/gimp > 98944b413813d8b4089abd121666d9dc801ed454 > : ba...@cyber[6]; pkg search 98944b413813d8b4089abd121666d9dc801ed454 > INDEX ACTION VALUE PACKAGE > 98944b413813d8b4089abd121666d9dc801ed454 file usr/bin/gimp-2.6 > pkg:/image/editor/g...@0.5.11-0.133 > : ba...@cyber[7];
It feels like a great deal of data has been lost. However, that is only a feeling and I do wonder if all the header information was valuable over the years and how many times have I really looked at it. I know that I certainly have looked. It would only take a few minutes but please consider the following somewhat odd case : (1) I have my own bit of code the implements the SHA256 message digest hash algorithm and I have written it such that it is POSIX ISO/IEC 9899:1995 compliant and thus all sources have this in it : /* Feature test switches */ #define _POSIX_SOURCE 1 (2) I compiled a set of objects on Solaris 8 with Studio 11 and then switched over to a Solaris 10 machine and did this : $ /opt/studio/SOS12.1/SUNWspro/bin/cc -v -Xc -xstrconst -xildoff \ > -xarch=v8 -xlibmil -xcode=pic32 -xlibmieee -xregs=no%appl -D_TS_ERRNO \ > -o SHA256 main.o sha256.o panic.o cwdname.o baud.o $ file SHA256 SHA256: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped (3) mcs now shows me that I have a mix of header versions involved : $ mcs -c SHA256 $ mcs -p SHA256 | sort -u @(#)dirent.h 1.29 99/03/11 SMI @(#)dirent.h 1.32 99/05/04 SMI @(#)errno.h 1.16 99/07/26 SMI @(#)errno.h 1.20 00/02/14 SMI @(#)feature_tests.h 1.18 99/07/26 SMI @(#)int_types.h 1.6 97/08/20 SMI @(#)isa_defs.h 1.20 99/05/04 SMI @(#)machsig.h 1.15 99/08/15 SMI @(#)machtypes.h 1.13 99/05/04 SMI @(#)procset.h 1.20 00/02/14 SMI @(#)resource.h 1.25 98/06/30 SMI @(#)select.h 1.16 98/04/27 SMI @(#)siginfo.h 1.54 98/03/27 SMI @(#)signal.h 1.38 99/08/10 SMI @(#)signal.h 1.54 99/07/26 SMI @(#)signal_iso.h 1.1 99/08/09 SMI @(#)stddef.h 1.16 99/08/10 SMI @(#)stddef_iso.h 1.1 99/08/09 SMI @(#)stdio.h 1.78 99/12/08 SMI @(#)stdio_impl.h 1.8 99/06/10 SMI @(#)stdio_iso.h 1.2 99/10/25 SMI @(#)stdio_tag.h 1.3 98/04/20 SMI @(#)stdlib.h 1.47 99/11/03 SMI @(#)stdlib_iso.h 1.3 02/10/10 SMI @(#)string.h 1.24 99/08/10 SMI @(#)string_iso.h 1.2 99/11/09 SMI @(#)termios.h 1.39 07/05/30 SMI @(#)termios.h 1.6 92/07/14 SMI @(#)time.h 1.39 99/08/10 SMI @(#)time.h 2.67 03/08/07 SMI @(#)time_impl.h 1.5 99/10/05 SMI @(#)time_iso.h 1.1 99/08/09 SMI @(#)types.h 1.69 03/08/07 SMI @(#)unistd.h 1.37 98/10/28 SMI @(#)unistd.h 1.58 99/11/11 SMI @(#)va_list.h 1.12 99/05/04 SMI @(#)wait.h 1.21 97/04/08 SMI CopyRight 2010 Blastwave.ORG Inc.,BLASTWAVE(R) 14Feb2010 SHA256: acomp: Sun C 5.8 Patch 121015-07 2009/04/22 as: Sun Compiler Common 11 Patch 120760-22 2009/05/07 cg: Sun Compiler Common 11 Patch 120760-22 2009/05/07 iropt: Sun Compiler Common 11 Patch 120760-22 2009/05/07 ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.497 Now then let's suppose that I do everything on Sol 10 ( I'll get to snv_134 in just a sec ) and to keep this brief I'll skip my assembly sources hackary entirely : . . . a whole set of steps precede this ... . $ /opt/studio/SOS12.1/SUNWspro/bin/cc $CFLAGS -I../src -DSPARC -c -o sha256.o ../src/sha256.c $ /opt/studio/SOS12.1/SUNWspro/bin/cc $CFLAGS -c -o baud.o ../src/baud.c $ /opt/studio/SOS12.1/SUNWspro/bin/cc $CFLAGS -c -o panic.o ../src/panic.c $ /opt/studio/SOS12.1/SUNWspro/bin/cc $CFLAGS -c -o cwdname.o ../src/cwdname.c $ /opt/studio/SOS12.1/SUNWspro/bin/cc $CFLAGS -o SHA256 main.o sha256.o panic.o cwdname.o baud.o $ file SHA256 SHA256: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped $ mcs -p SHA256 | sort -u @(#)ccompile.h 1.2 04/11/08 SMI @(#)dirent.h 1.36 04/09/28 SMI @(#)dirent.h 1.37 04/09/28 SMI @(#)errno.h 1.17 03/01/03 SMI @(#)errno.h 1.20 00/01/12 SMI @(#)feature_tests.h 1.25 07/02/02 SMI @(#)int_types.h 1.10 04/09/28 SMI @(#)isa_defs.h 1.29 08/06/06 SMI @(#)machsig.h 1.15 99/08/15 SMI @(#)machtypes.h 1.13 99/05/04 SMI @(#)procset.h 1.25 04/07/16 SMI @(#)resource.h 1.37 07/02/07 SMI @(#)select.h 1.19 04/01/28 SMI @(#)siginfo.h 1.59 04/07/15 SMI @(#)signal.h 1.43 04/09/28 SMI @(#)signal.h 1.66 04/09/28 SMI @(#)signal_iso.h 1.1 99/08/09 SMI @(#)signal_iso.h 1.6 03/05/02 SMI @(#)stddef.h 1.18 04/09/28 SMI @(#)stddef_iso.h 1.2 03/03/06 SMI @(#)stdio.h 1.84 04/09/28 SMI @(#)stdio_c99.h 1.2 04/03/29 SMI @(#)stdio_impl.h 1.15 07/03/05 SMI @(#)stdio_iso.h 1.8 05/08/16 SMI @(#)stdio_tag.h 1.4 04/09/28 SMI @(#)stdlib.h 1.51 04/06/30 SMI @(#)stdlib_c99.h 1.2 04/03/29 SMI @(#)stdlib_iso.h 1.9 04/09/28 SMI @(#)string.h 1.27 07/01/14 SMI @(#)string_iso.h 1.5 04/06/18 SMI @(#)termios.h 1.42 07/01/14 SMI @(#)termios.h 1.6 92/07/14 SMI @(#)time.h 1.45 08/01/09 SMI @(#)time.h 2.77 09/06/02 SMI @(#)time_impl.h 1.11 05/05/19 SMI @(#)time_iso.h 1.4 04/09/07 SMI @(#)types.h 1.86 07/09/20 SMI @(#)unistd.h 1.43 06/03/10 SMI @(#)unistd.h 1.76 06/03/10 SMI @(#)va_list.h 1.15 04/11/19 SMI @(#)wait.h 1.23 04/06/03 SMI CopyRight 2010 Blastwave.ORG Inc.,BLASTWAVE(R) 2010/02/14 SHA256: acomp: Sun C 5.10 SunOS_sparc Patch 141861-03 2009/12/03 as: Sun Compiler Common 12.1 SunOS_sparc 2009/06/03 ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.497 Now I see stdio_c99.h 1.2 04/03/29 which did not exist before as well as other little items. Everything seeems to work as expected : $ ls -l /usr/xpg6/bin/ls -r-xr-xr-x 1 root bin 27380 Jun 11 2008 /usr/xpg6/bin/ls $ digest -a sha256 /usr/xpg6/bin/ls 88ad5cfb18fc9d5dbc06ddf79e83e63e92f934da62579bd05eda776e3dfff091 $ ./SHA256 /usr/xpg6/bin/ls 88ad5cfb18fc9d5dbc06ddf79e83e63e92f934da62579bd05eda776e3dfff091 ... but on snv_134 I *feel* that I am losing a pile of information that was there before. $ uname -a SunOS aequitas 5.11 snv_134 i86pc i386 i86pc $ which cc /opt/studio/SOS12.1/SUNWspro/bin/cc $ echo $CFLAGS -xstrconst -xildoff -xarch=386 -xnolibmil -Xa -Kpic -xregs=no%frameptr -xlibmieee -g -Qy -xs -D_TS_ERRNO To be honest I could use -Xc there but anyways here goes : $ file SHA256 SHA256: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, not stripped $ mcs -p SHA256 | sort -u %Z%%M% %I% %E% SMI CopyRight 2010 Blastwave.ORG Inc.,BLASTWAVE(R) 2010/02/14 SHA256: acomp: Sun C 5.10 SunOS_i386 Patch 142363-03 2009/12/03 as: Sun Compiler Common 12.1 SunOS_i386 Patch 141858-04 2009/12/08 ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.1689 Things seem to work as expected regardless : $ ls -l /usr/xpg6/bin/ls -r-xr-xr-x 1 root bin 48760 Feb 19 04:08 /usr/xpg6/bin/ls $ digest -a sha256 /usr/xpg6/bin/ls 9523735ea5384d0feb40fc4b99d3336024f6d3360ea383761c780c5d8767782d $ ./SHA256 /usr/xpg6/bin/ls 9523735ea5384d0feb40fc4b99d3336024f6d3360ea383761c780c5d8767782d Lastly, if I keep around even one object file that was compiled on Solaris 8 I see this : $ mcs -p SHA256 | sort -u %Z%%M% %I% %E% SMI @(#)dirent.h 1.29 99/03/11 SMI @(#)dirent.h 1.32 99/05/04 SMI @(#)errno.h 1.16 99/07/26 SMI @(#)errno.h 1.20 00/02/14 SMI @(#)feature_tests.h 1.18 99/07/26 SMI @(#)int_types.h 1.6 97/08/20 SMI @(#)isa_defs.h 1.20 99/05/04 SMI @(#)machtypes.h 1.1 99/05/04 SMI @(#)machtypes.h 1.8 99/05/04 SMI @(#)signal.h 1.38 99/08/10 SMI @(#)signal.h 1.54 99/07/26 SMI @(#)signal_iso.h 1.1 99/08/09 SMI @(#)stdio.h 1.78 99/12/08 SMI @(#)stdio_impl.h 1.8 99/06/10 SMI @(#)stdio_iso.h 1.2 99/10/25 SMI @(#)stdio_tag.h 1.3 98/04/20 SMI @(#)stdlib.h 1.47 99/11/03 SMI @(#)stdlib_iso.h 1.3 02/10/10 SMI @(#)string.h 1.24 99/08/10 SMI @(#)string_iso.h 1.2 99/11/09 SMI @(#)types.h 1.69 03/08/07 SMI @(#)unistd.h 1.37 98/10/28 SMI @(#)unistd.h 1.58 99/11/11 SMI @(#)va_list.h 1.12 99/05/04 SMI CopyRight 2010 Blastwave.ORG Inc.,BLASTWAVE(R) 2010/02/25 SHA256: acomp: Sun C 5.10 SunOS_i386 Patch 142363-03 2009/12/03 acomp: Sun C 5.8 Patch 121016-08 2009/04/20 as: Sun Compiler Common 11 Patch 120759-20 2009/04/20 as: Sun Compiler Common 12.1 SunOS_i386 Patch 141858-04 2009/12/08 ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.1689 Sorry for the long winding email but I am really thinking that the header data is nice to have around and still useful. Is there some easy way to get that data back ( an awesome awk/sed/grep script ) or is it lost forever? -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
