From owner-svn-src-all@FreeBSD.ORG Fri Oct 15 07:36:19 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BFC2106566C; Fri, 15 Oct 2010 07:36:19 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp3.one.com (csmtp3.one.com [91.198.169.23]) by mx1.freebsd.org (Postfix) with ESMTP id 1FCB88FC0A; Fri, 15 Oct 2010 07:36:18 +0000 (UTC) Received: from [192.168.0.22] (0x573fa596.cpe.ge-1-1-0-1109.ronqu1.customer.tele.dk [87.63.165.150]) by csmtp3.one.com (Postfix) with ESMTP id 239BE240642F; Fri, 15 Oct 2010 07:36:17 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-57--416668630; protocol="application/pkcs7-signature"; micalg=sha1 From: Erik Cederstrand In-Reply-To: <20101015112704.I1144@besplex.bde.org> Date: Fri, 15 Oct 2010 09:36:16 +0200 Message-Id: References: <201010090531.o995V8n3026865@svn.freebsd.org> <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> To: Bruce Evans X-Mailer: Apple Mail (2.1081) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Tim Kientzle , src-committers@freebsd.org, Ben Kaduk Subject: Re: svn commit: r213643 - head/usr.bin/ar X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 07:36:19 -0000 --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--