From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14667 invoked by alias); 21 Sep 2017 15:46:31 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 14585 invoked by uid 89); 21 Sep 2017 15:46:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_00,KAM_INFOUSMEBIZ,KAM_LAZY_DOMAIN_SECURITY,RDNS_DYNAMIC autolearn=no version=3.3.2 spammy=H*M:info, H*F:D*info X-Spam-User: qpsmtpd, 2 recipients X-HELO: void-ptr.info Received: from pppoe.185.44.68.223.lanport.ru (HELO void-ptr.info) (185.44.68.223) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 21 Sep 2017 15:46:28 +0000 Received: from ptr by void-ptr.info with local (Exim 4.72) (envelope-from ) id 1dv3g7-0004Bq-Cm; Thu, 21 Sep 2017 18:46:15 +0300 Date: Thu, 21 Sep 2017 15:46:00 -0000 From: Petr Ovtchenkov To: Simon Marchi Cc: Pedro Alves , Matt Rice , Fiodar Stryzhniou , Andreas Schwab , Binutils , Joel Brobecker , Matthias Klose , GDB Subject: Re: meaning of "Automatic date update in version.in" commits Message-ID: <20170921184615.6b1e5d44@void-ptr.info> In-Reply-To: References: <20170921135845.479dfc76@void-ptr.info> <024439c7-2083-d368-0138-2160e4494b81@redhat.com> <20170921152240.16bb4cc0@void-ptr.info> <8740f2a7-1300-3116-f34b-5487a8cd8b2b@redhat.com> <20170921161743.3ddc6bb9@void-ptr.info> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg00080.txt.bz2 On Thu, 21 Sep 2017 15:25:53 +0200 Simon Marchi wrote: > On 2017-09-21 15:17, Petr Ovtchenkov wrote: > > And date stamp in version.in not play here at all. But, > > > > - if you insert date stamp into sources, you > > i) keep "litter" problem > > ii) make misorientation (what this date mean? commit date? - it > > already > > present in commit; and what commit date?) > > - if you don't insert date stamp into sources, but add to SONAME > > during build process, > > it still not reflect ABI compatibilities, but may prevent "binary > > reproducible builds" > > (depends upon what date you use). I'm underline, that such addition > > has no relation to ABI compatibilities, so such SONAME modification > > lose sense. > > Binary reproducible builds mean that if you and I start with the same > source code and same build tools, we will get exactly the same build > artifacts. Here the build can't "depend on what date you use": If "date stamp" inserted into binary is a build date, then we will have different binaries. If we will use something else, for example "last commit" date, then we may have "same" build, but may not. From equality of "last commit" date not follow binary equivalence (consider cherry-picked commit, for example, or variations of sample "git diff 3110f4be18a2 f625a739" I show above). > you > can't choose a date or another, the date is part of the code you are > trying to build. So if you and I build from the same commit, we'll > build using the same date, whatever date is in the version.h file. > >