ar and ranlib -D

[John D. Hendrickson and Sara Darnell]

Warner Losh wrote:
> On Apr 10, 2014, at 3:45 PM, John D. Hendrickson and Sara Darnell <johnandsara2 at cox.net> wrote:
> 
>> Warner Losh wrote:
>>> On Apr 10, 2014, at 9:22 AM, Ed Maste <emaste at freebsd.org> wrote:
>>>> On 10 April 2014 11:06, Dag-Erling Smørgrav <des at 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’t 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’m surprised this isn’t the default behavior. Given that we always
>>> rebuild, though, this change is totally safe.
>>> Warner
>>> _______________________________________________
>>> freebsd-arch at freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
>>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>> i can't confirm a ar needs inner timestamps as an interface dependancy  issue or that software depends on this format
>>
>> 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)
>>
>> but you all aren't saying you've done any research
>>
>> 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.
>>
>> does install(1) strip this info at the final stage ? never mind
>>
>> no.  these days people always build such and such a way. bull.
>>
>> ar is used by assemblers not just gcc(1)
>>
>> some people insert and remove asm libraries by hand.  all what the job requires to get done.
>>
>> any argument "these days we will only allow".  no.  that's messing up what had already worked right ?
>>
>> ok well good luck
> 
> In the tree, we do none of these things, so the change is safe. The kernel doesn’t care, the user land .a files don’t 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
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
> 

i think your fine since BSD so far has an excellent original source 
tree to fall back on and no one will depend on the change per say

i don't run BSD so i can't confirm your libtools even stores/reads 
time in ar's

i was hoping you didn't think i meant compile literal  (i meant when 
it's final link time resetting is fine, while it's being made too much 
is going on to say for sure who when needs a dependancy stamp before)

i think your on track fine if your objective is release time sanity. 
i only meant to highlight things to think about i almost wish i hadn't

well, good luck again