From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73110 invoked by alias); 21 Sep 2017 13:17:55 -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 73048 invoked by uid 89); 21 Sep 2017 13:17:54 -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=merit, H*M:info, claim, 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 13:17:49 +0000 Received: from ptr by void-ptr.info with local (Exim 4.72) (envelope-from ) id 1dv1MN-0003wB-Bq; Thu, 21 Sep 2017 16:17:43 +0300 Date: Thu, 21 Sep 2017 13:17:00 -0000 From: Petr Ovtchenkov To: Pedro Alves Cc: 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: <20170921161743.3ddc6bb9@void-ptr.info> In-Reply-To: <8740f2a7-1300-3116-f34b-5487a8cd8b2b@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg00078.txt.bz2 On Thu, 21 Sep 2017 13:39:08 +0100 Pedro Alves wrote: > > On 09/21/2017 01:22 PM, Petr Ovtchenkov wrote: > > On Thu, 21 Sep 2017 12:36:46 +0100 > > Pedro Alves wrote: > > >> I.e., this whole thread feels like the classical XY problem. > >> > >> What is the actual problem that you're trying to solve? > > > > Problem remains original. > > > > "Automatic date update in version.in" commits are > > - litter commits tree > > - create problems for deterministic, bit-identical and/or verifiable builds. > > [snip distractions from the original problem] > > > Am I quite clear? > > No. > > The "litter" problem is real, but minor. Nice. Looks, that in first point we have consensus. :) > > The determinism claim would have merit, if it were a real problem. I think it's real. But it is another story, right? > But it's not. Every checkout of a given git hash gets the exact > same sources with the same date stamp. It's totally deterministic. 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. > > So again, what problem are you trying to solve? > Again, all stated above. WBR, -- - ptr