From owner-freebsd-arch@FreeBSD.ORG Thu Apr 10 21:53:53 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A2A49655 for ; Thu, 10 Apr 2014 21:53:52 +0000 (UTC) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 95BF21901 for ; Thu, 10 Apr 2014 21:53:52 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id lx4so4594315iec.38 for ; Thu, 10 Apr 2014 14:53:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ALr1nfxHFuW/YtcxFQ5q2kiI33UC9hi1Pb5bLJTgeuU=; b=m93Rnxj66zfM93mlp6EM/vx6j/OI16qOKaNTdEGYJng5ilRpezLXptwpKCCtljucas N1w7Yg8GOFmVm7wAqHgiGNq7n4lMQOR42YWTxjycJO2TPIftsP2SZygAkTHMZFtk4R/5 rzF3bPD/LWAVJcDcWJam2TQTyQ38TFVRYP8cLC/5g7rqA7I0E/3fVeyB9tVPvibglqNP Xiej2u8i/CxN5gMAbcfJCaEAdNd6wDTcSnj8Zsv4PuYXU2HZlQzdVb03aIuOTTxMk5MV UgtwIo9ouLOkSrAME1uD4N4wtKqqjdq+EtfCrlOSqIO/zYoO+BAFp75Ad55jwBDl3gba 6U0g== X-Gm-Message-State: ALoCoQld8eRdSxShrbWr5jzeUtW9RSyMXNtpbHrZ90ga+V/l2DiIrdT8RhhLLxNsjqfHIb5dq3RC X-Received: by 10.42.199.144 with SMTP id es16mr3247757icb.87.1397166826564; Thu, 10 Apr 2014 14:53:46 -0700 (PDT) Received: from [10.0.0.119] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id s9sm513074igw.16.2014.04.10.14.53.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Apr 2014 14:53:45 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: ar and ranlib -D From: Warner Losh In-Reply-To: <534710F4.1040908@cox.net> Date: Thu, 10 Apr 2014 15:53:44 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <5C84C980-BBD6-48F0-914A-220B5DB77A5A@bsdimp.com> References: <86eh15usv2.fsf@nine.des.no> <534710F4.1040908@cox.net> To: johnandsara2@cox.net X-Mailer: Apple Mail (2.1874) Cc: =?windows-1252?Q?Dag-Erling_Sm=F8rgrav?= , Ed Maste , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 21:53:53 -0000 On Apr 10, 2014, at 3:45 PM, John D. Hendrickson and Sara Darnell = wrote: > Warner Losh wrote: >> On Apr 10, 2014, at 9:22 AM, Ed Maste wrote: >>> On 10 April 2014 11:06, Dag-Erling Sm=F8rgrav wrote: >>>> The attached patch adds -D to ARFLAGS and introduces RANLIBFLAGS = which >>>> defaults to -D. This ensures that all timestamps inside static >>>> libraries in the base system are hardcoded to 0 (aka the epoch), = which >>>> is a huge step towards fully reproducible builds. Any objections? >>> Looks good to me, I'm not sure why this didn't happen long ago. >> Once upon a time, ranlib didn=92t like this too well and complained = that >> the index was older than the file. Then it was made a special case. = These >> days (and these days includes time since ~1995 or 2000), people >> always rebuild the entire .a anyway, so the value of having a = timestamp >> in there is low, at best, so always doing this has become so boring >> that i=92m surprised this isn=92t the default behavior. Given that we = always >> rebuild, though, this change is totally safe. >> Warner >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org" >=20 > i can't confirm a ar needs inner timestamps as an interface dependancy = issue or that software depends on this format >=20 > however it does make sense IF AND ONLY IF the timestamp are used for = compilation order dependancy, and compilation is about mapping holes by = dependancy, it's ok for releasetime AFTER compiling (NOT during = compiling) >=20 > but you all aren't saying you've done any research >=20 > but i don't know if any kernels use it with lib version as a link to = and extended interface or as a flag. i don't know if any existing = software crashes if the value is 0. >=20 > does install(1) strip this info at the final stage ? never mind >=20 > no. these days people always build such and such a way. bull. >=20 > ar is used by assemblers not just gcc(1) >=20 > some people insert and remove asm libraries by hand. all what the job = requires to get done. >=20 > any argument "these days we will only allow". no. that's messing up = what had already worked right ? >=20 > ok well good luck In the tree, we do none of these things, so the change is safe. The = kernel doesn=92t care, the user land .a files don=92t care since we = always rebuild them and never insert. Outside the tree, people use bsd.lib.mk, which does things the way I say = so the change is safe. Outside of that, these changes make no difference, especially for the = use cases you describe, so that is safe. What am I missing? Warner=