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