Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Matthias Klose <doko@ubuntu.com>
To: Petr Ovtchenkov <ptr@void-ptr.info>,
	       Simon Marchi <simon.marchi@polymtl.ca>
Cc: Pedro Alves <palves@redhat.com>, Matt Rice <ratmice@gmail.com>,
	       Fiodar Stryzhniou <fedor_qd@mail.ru>,
	       Andreas Schwab <schwab@linux-m68k.org>,
	       Binutils <binutils@sourceware.org>,
	       Joel Brobecker <brobecker@adacore.com>,
	GDB <gdb@sourceware.org>
Subject: Re: meaning of "Automatic date update in version.in" commits
Date: Thu, 21 Sep 2017 16:03:00 -0000	[thread overview]
Message-ID: <426b9fdf-a854-6d5f-b296-df71ad0c1561@ubuntu.com> (raw)
In-Reply-To: <20170921184615.6b1e5d44@void-ptr.info>

On 21.09.2017 17:46, Petr Ovtchenkov wrote:
> On Thu, 21 Sep 2017 15:25:53 +0200
> Simon Marchi <simon.marchi@polymtl.ca> 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.

but it not a build date. it is a string taken form a file in the repository.
That's exactly what Simon wrote at the end of the last message, and which you
ignored to read or comment. Please see below.

> 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.
>>
>>


  parent reply	other threads:[~2017-09-21 16:03 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-21  5:03 Fiodar Stryzhniou via gdb
2017-09-21  8:42 ` Matt Rice
2017-09-21 10:58   ` Petr Ovtchenkov
2017-09-21 11:37     ` Pedro Alves
     [not found]       ` <20170921152240.16bb4cc0@void-ptr.info>
2017-09-21 12:39         ` Pedro Alves
2017-09-21 13:17           ` Petr Ovtchenkov
2017-09-21 13:34             ` Simon Marchi
2017-09-21 15:46               ` Petr Ovtchenkov
2017-09-21 16:01                 ` Simon Marchi
2017-09-21 16:03                 ` Matthias Klose [this message]
2017-09-21 16:26                   ` Petr Ovtchenkov
2017-09-21 16:34                     ` Joel Brobecker
2017-09-21 16:52                       ` Petr Ovtchenkov
2017-09-21 17:00                         ` Joel Brobecker
2017-09-21 17:39                           ` Petr Ovtchenkov
2017-09-21 23:59                             ` Alan Modra
2017-09-22  5:31                               ` Petr Ovtchenkov
2017-09-22  6:49                                 ` Andreas Schwab
2017-09-22  9:29                                   ` Petr Ovtchenkov
2017-09-22 22:26                                   ` H.J. Lu
2017-09-22 22:35                                   ` H.J. Lu
2017-09-22  9:49                               ` [PATCH] bfd/version.h: Add rationale for BFD_VERSION_DATE (Re: meaning of "Automatic date update in version.in" commits) Pedro Alves
2017-09-22 13:38                                 ` Alan Modra
2017-09-22 13:47                                   ` Joel Brobecker
2017-09-22 13:59                                     ` Pedro Alves
2017-09-21 17:17   ` meaning of "Automatic date update in version.in" commits Joseph Myers
2017-09-21 17:31     ` Matt Rice
     [not found] <20170920173622.28500ccf@void-ptr.info>
2017-09-20 15:05 ` Joel Brobecker
2017-09-20 15:33   ` Petr Ovtchenkov
2017-09-21 17:07     ` Ian Lance Taylor via gdb
2017-09-20 15:40   ` Matthias Klose
2017-09-20 15:48     ` Dmitry Samersoff
     [not found] ` <87zi9p2vma.fsf@linux-m68k.org>
2017-09-20 17:24   ` Petr Ovtchenkov
     [not found]     ` <7217d33d-61eb-732e-dfd6-80ef4908743e@ubuntu.com>
2017-09-20 19:21       ` Petr Ovtchenkov
2017-09-20 19:27       ` Mikhail Terekhov
2017-09-20 19:56         ` Philippe Waroquiers
2017-09-20 19:57         ` Matthias Klose
2017-09-20 20:07           ` Philippe Waroquiers
2017-09-20 20:21             ` Matthias Klose
2017-09-20 20:26               ` Philippe Waroquiers
2017-09-20 20:31                 ` Petr Ovtchenkov
2017-09-20 20:39                   ` Philippe Waroquiers
2017-09-20 20:34           ` Mikhail Terekhov
2017-09-20 21:34     ` Andreas Schwab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=426b9fdf-a854-6d5f-b296-df71ad0c1561@ubuntu.com \
    --to=doko@ubuntu.com \
    --cc=binutils@sourceware.org \
    --cc=brobecker@adacore.com \
    --cc=fedor_qd@mail.ru \
    --cc=gdb@sourceware.org \
    --cc=palves@redhat.com \
    --cc=ptr@void-ptr.info \
    --cc=ratmice@gmail.com \
    --cc=schwab@linux-m68k.org \
    --cc=simon.marchi@polymtl.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox