This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Disabling timestamps, was Re: [PATCH roland/Versions.def]....
- From: Roland McGrath <roland at hack dot frob dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Brooks Moses <bmoses at google dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Fri, 14 Mar 2014 16:03:43 -0700 (PDT)
- Subject: Re: Disabling timestamps, was Re: [PATCH roland/Versions.def]....
- Authentication-results: sourceware.org; auth=none
- References: <20140228214559 dot BD8BF744B6 at topped-with-meat dot com> <53236661 dot 7070509 at redhat dot com> <53237C9C dot 2030504 at google dot com> <53237FC3 dot 4010002 at redhat dot com>
> On 03/14/2014 06:03 PM, Brooks Moses wrote:
> > On 03/14/2014 01:28 PM, Carlos O'Donell wrote:
> > This suggests a related point -- we have a local patch to turn off
> > the date stamp in csu/Makefile, as part of our process of doing
> > repeatable builds.
That whole linux-only bit in the version-info.h rule is just pointless.
I'll remove it now.
> > Is there any interest in having this upstream? The local patch is
> > really trivial, but an upstream version would want a configure option
> > and would need some additional pieces to ensure determinism (most
> > notably, including "D" as an ar option, and presumably doing
> > something with build-ids if one is using a GCC where they're normally
> > enabled).
I'm in favor of using D, and in fact if asked I'd say always build binutils
with --enable-deterministic-archives so D is the default. But it's vaguely
plausible that something somewhere gets unhappy about installed libc.a
having all zeros, so we should be somewhat circumspect about the change.
I designed Build ID with reproducible builds in mind to begin with. If
everything else is identical (including debug info), then the build ID is
identical too. If the debug info is different, then the build ID should
not be the same. If you are considering munging build IDs with bespoke
magic (aside from regenerating when changing the file contents, as rpm's
debugedit does after it changes source directory names in the DWARF), then
IMHO you are Doing It Wrong.
> I'd be interested in having more repeatable builds.
Agreed.
> Anything that simplifies that process of comparing two builds is good
> step in the right direction.
"Anything" permits a lot of harebrained ideas I will object to, so I won't
exactly concur with this. :-)
> If the only difference is debug information, then I'm going to be
> happy.
If you are really trying, then the debug information comes out identical
too. (Or, worst case, differs in directory names that can be massaged by
something like debugedit.) In Fedoraland, this should already be the case
with mock/koji builds across the board.
Thanks,
Roland