This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]