Date: Thu, 10 Apr 2014 15:53:44 -0600 From: Warner Losh <imp@bsdimp.com> To: johnandsara2@cox.net Cc: =?windows-1252?Q?Dag-Erling_Sm=F8rgrav?= <des@des.no>, Ed Maste <emaste@freebsd.org>, "freebsd-arch@freebsd.org" <arch@freebsd.org> Subject: Re: ar and ranlib -D Message-ID: <5C84C980-BBD6-48F0-914A-220B5DB77A5A@bsdimp.com> In-Reply-To: <534710F4.1040908@cox.net> References: <86eh15usv2.fsf@nine.des.no> <CAPyFy2Ct-GJOy=x2ZwXQJnZdf0BbGm7VmTQcqc1U9Zxzkx7YQg@mail.gmail.com> <oGHX1n00K2X408g01GHYZ5> <534710F4.1040908@cox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 10, 2014, at 3:45 PM, John D. Hendrickson and Sara Darnell = <johnandsara2@cox.net> wrote: > Warner Losh wrote: >> On Apr 10, 2014, at 9:22 AM, Ed Maste <emaste@freebsd.org> wrote: >>> On 10 April 2014 11:06, Dag-Erling Sm=F8rgrav <des@des.no> 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5C84C980-BBD6-48F0-914A-220B5DB77A5A>