This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: meaning of "Automatic date update in version.in" commits
On 20.09.2017 21:26, Mikhail Terekhov wrote:
> On 09/20/17 14:14, Matthias Klose wrote:
>> On 20.09.2017 19:23, Petr Ovtchenkov wrote:
>>> On Wed, 20 Sep 2017 18:16:45 +0200
>>> Andreas Schwab <schwab@linux-m68k.org> wrote:
>>>
>>>> On Sep 20 2017, Petr Ovtchenkov <ptr@void-ptr.info> wrote:
>>>>
>>>>> What is the meaning of "Automatic date update in version.in" commits?
>>>>> I mean commits like f625a739e5.
>>>> It is used to name the shared libbfd and libopcodes, since there is no
>>>> stable ABI.
>>>>
>>>>> This commits litter commits tree and create problems for
>>>>> deterministic, bit-identical and/or verifiable builds.
>>>> Why is that a problem? The version is fixed for a particular source
>>>> snapshot.
>>>>
>>> It's looks as a problem indeed:
>>> - garbage in commits
>>> - disorientation, when date present in SONAME
>>> 0x000000000000000e (SONAME) Library soname:
>>> [libbfd-2.29.0.20170729.so]
>> this is correct, and it's usually set to not include the date for a releases, an
>> exception being the 2.29.1 release, but things happen.
>>
>>> You see:
>>>
>>> git show 3110f4be18a2
>>> commit 3110f4be18a2f3b9fcd9663ed1dd141bbd6ed14f
>>> Author: GDB Administrator <gdbadmin@sourceware.org>
>>> Date: Wed Sep 20 00:01:01 2017 +0000
>>>
>>> Automatic date update in version.in
>>>
>>> diff --git a/bfd/version.h b/bfd/version.h
>>> index 3405e42..955269f 100644
>>> --- a/bfd/version.h
>>> +++ b/bfd/version.h
>>> @@ -1,4 +1,4 @@
>>> -#define BFD_VERSION_DATE 20170919
>>> +#define BFD_VERSION_DATE 20170920
>>> #define BFD_VERSION @bfd_version@
>>> #define BFD_VERSION_STRING @bfd_version_package@ @bfd_version_string@
>>> #define REPORT_BUGS_TO @report_bugs_to@
>>>
>>> git show f625a739
>>> commit f625a739e567f0110b2675539b7a0e5d5f67c5dc
>>> Author: GDB Administrator <gdbadmin@sourceware.org>
>>> Date: Wed Sep 20 00:01:22 2017 +0000
>>>
>>> Automatic date update in version.in
>>>
>>> diff --git a/bfd/version.h b/bfd/version.h
>>> index 3405e42..955269f 100644
>>> --- a/bfd/version.h
>>> +++ b/bfd/version.h
>>> @@ -1,4 +1,4 @@
>>> -#define BFD_VERSION_DATE 20170919
>>> +#define BFD_VERSION_DATE 20170920
>>> #define BFD_VERSION @bfd_version@
>>> #define BFD_VERSION_STRING @bfd_version_package@ @bfd_version_string@
>>> #define REPORT_BUGS_TO @report_bugs_to@
>>>
>>> git diff 3110f4be18a2 f625a739
>>> ...
>>> Ooops....
>>>
>>> This approch produce ambiguity, but try to conceal it.
>> Feel free to limit the bumps to exactly one after another commit.
>>
> What if build scripts obtain date of last commit automatically i.e. something
> like this:
>
> ~/tmp/gdb/binutils-gdb (master)>git log -1 --format=%cd --date=format:%Y%m%d
> 20170920
>
> Then there is no need for additional commit.
no, you can't assume that git is available for builds.