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 2017-09-21 17:46, Petr Ovtchenkov wrote:
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,

It is definitely not a build date (as in the date at which you run make), I don't think anybody is suggesting that.

then we will have different
binaries. 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).

That's the part I don't understand in your reasoning.

f625a739 is the commit that bumps the date to Sept 20 in the binutils-2_29-branch, 3110f4be18a2 is the commit that bumps the date to Sept 20 in the gdb-8.0-branch. They happen to have the same title and same diff, but they are otherwise not related. Those two branches do not contain the same code, and therefore are not expected to produce the same build artifacts.

So if you checkout the repo at f625a739 (state at which the gdb 8.0 branch was on Sept 20) and I do the same, we'll be able to get reproducible builds if we use the same toolchain (unless something else entirely causes the build to not be reproducible, I haven't tried).

Simon


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