This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: meaning of "Automatic date update in version.in" commits
On Thu, 21 Sep 2017 18:01:59 +0200
Matthias Klose <doko@ubuntu.com> wrote:
> 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.
Ok. I just expect that you read my arguments too. But in this case you ignore
<snip>
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....
</snip>
Same date. From both commits I can build libbfd. From equality of dates stamped in the source
not follow ABI compatibility.
Plus
git diff 0d8a80b95 7a261482f
---from different stamped dates not follow ABI incompatibility.
Or I suspect that you conceal that date stamp not intended to reflect ABI compatibility,
but something else.
>
> > 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.