Date: Fri, 15 Oct 2010 09:36:16 +0200 From: Erik Cederstrand <erik@cederstrand.dk> To: Bruce Evans <brde@optusnet.com.au> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Tim Kientzle <kientzle@freebsd.org>, src-committers@freebsd.org, Ben Kaduk <minimarmot@gmail.com> Subject: Re: svn commit: r213643 - head/usr.bin/ar Message-ID: <E5C0B975-A20C-46C5-ACF1-CE6D2470BCBA@cederstrand.dk> In-Reply-To: <20101015112704.I1144@besplex.bde.org> References: <201010090531.o995V8n3026865@svn.freebsd.org> <AANLkTim8kj2X7fJMyRHTsXWFs8tvE07439w3Rzan7W1e@mail.gmail.com> <8C667EA1-3012-4499-BCCE-58263165663B@cederstrand.dk> <20101010083725.S3587@besplex.bde.org> <2A26ECE8-7713-49C4-8706-5AA5B232BE29@cederstrand.dk> <20101013143845.I1817@besplex.bde.org> <5D7F8DAF-E127-41C0-927B-1D72EFC8F4C4@cederstrand.dk> <20101015112704.I1144@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail-57--416668630 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Den 15/10/2010 kl. 02.42 skrev Bruce Evans: >=20 > 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=3D-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= --Apple-Mail-57--416668630--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E5C0B975-A20C-46C5-ACF1-CE6D2470BCBA>