Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@polymtl.ca>
To: Petr Ovtchenkov <ptr@void-ptr.info>
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>,
	       Matthias Klose <doko@ubuntu.com>, GDB <gdb@sourceware.org>
Subject: Re: meaning of "Automatic date update in version.in" commits
Date: Thu, 21 Sep 2017 13:34:00 -0000	[thread overview]
Message-ID: <c0803d26603c37f8b637e7cfe401a784@polymtl.ca> (raw)
In-Reply-To: <20170921161743.3ddc6bb9@void-ptr.info>

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



  reply	other threads:[~2017-09-21 13:34 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 [this message]
2017-09-21 15:46               ` Petr Ovtchenkov
2017-09-21 16:01                 ` Simon Marchi
2017-09-21 16:03                 ` Matthias Klose
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=c0803d26603c37f8b637e7cfe401a784@polymtl.ca \
    --to=simon.marchi@polymtl.ca \
    --cc=binutils@sourceware.org \
    --cc=brobecker@adacore.com \
    --cc=doko@ubuntu.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 \
    /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