svn commit: r213643 - head/usr.bin/ar

[Erik Cederstrand]

Den 15/10/2010 kl. 02.42 skrev Bruce Evans:
> 
> install(1) mainly compares bytes.  Thus it can consider changed metadata
> in inodes (mainly timestamps) to be irrelevant.  This cannot handle metadata
> (like timestamps) within the file.  strip(1) and objcopy(1) will clobber
> external timestamps, at least if they change the contents.  install -p is
> partly to recover from such clobbering (but install has special knowledge
> of strip, and IIRC it uses the timestamps of the unstripped file).
> Sometimes they will remove internal metadata and thus allow the modified
> files to compare equal.  A useful example of this is stripping debug info. Just
> adding a comment in a new line in a C source file will change the
> line numbers in the debugging info for all subsequent lines (that generate
> code).

Yes, I found out that "strip --strip-debug file.a" makes some of the files comparable.

At least some of the debugging info is there because the relevant Makefile overrides DEBUG_FLAGS (e.g. bthidd). I could revert these. Also, kernel modules will probably be comparable when I comment out "makeoptions DEBUG=-g" from the kernel config file.

Unless it makes sense to change all debugging info to store relative paths, the distribution will have to be built without debugging info. I have no idea if relative paths make sense in relation to gdb, though.

>  Putting build dates in object files using __DATE_ and __TIME__ in
> C source files would be less annoying if they were put in a separate
> section that could be stripped, but this is not very easy to at the
> source level.

This should be OK. It doesn't look like __DATE__ and __TIME__ are actually used in the source. They show up in LLVM and GCC, but only to document or implement support for them. named and ficl use them, but guarded by build options.

> Version control ids are already normally put in a special
> section, but I think it has other stuff in it that must not be stripped.
> Normally you shouldn't strip them, but they might affect the object files
> too much if they contain too much info about the checkout place or time.

This would normally be OK to record in the binary, unless the revision doesn't change functional behavior (e.g. comment changes or variable renaming). There may also be an issue of local timezones of the revision dates.

Regarding freebsd.cf, freebsd.submit.cf, sendmail.cf and submit.cf, it looks like I can edit contrib/sendmail/cf/sh/makeinfo.sh to produce a generic message instead of the build date.

I'll give it a new go when I have access to my fast build machine again next week.

Thanks,
Erik