GNU bug report logs - #25752
go incremental builds broken

Previous Next

Full log

View this message in rfc822 format

From: ludo <at> gnu.org (Ludovic Courtès)
To: Hank Donnay <hdonnay <at> gmail.com>
Cc: 25752 <at> debbugs.gnu.org
Subject: bug#25752: go incremental builds broken
Date: Tue, 07 Mar 2017 22:50:00 +0100

Hello,

Hank Donnay <hdonnay <at> gmail.com> skribis:

> The function for determining staleness is here (after the giant
> comment explaining the reasoning):
> https://golang.org/src/cmd/go/pkg.go#L1111

This method relies on the build ID to, which is defined like this (info
"(ld) Options"):

  `--build-id'
  `--build-id=STYLE'
       Request the creation of a `.note.gnu.build-id' ELF note section or
       a `.buildid' COFF section.  The contents of the note are unique
       bits identifying this linked file.  STYLE can be `uuid' to use 128
       random bits, `sha1' to use a 160-bit SHA1 hash on the normative
       parts of the output contents, `md5' to use a 128-bit MD5 hash on
       the normative parts of the output contents, or `0xHEXSTRING' to
       use a chosen bit string specified as an even number of hexadecimal
       digits (`-' and `:' characters between digit pairs are ignored).
       If STYLE is omitted, `sha1' is used.

       The `md5' and `sha1' styles produces an identifier that is always
       the same in an identical output file, but will be unique among all
       nonidentical output files.  It is not intended to be compared as a
       checksum for the file's contents.  A linked file may be changed
       later by other tools, but the build ID bit string identifying the
       original linked file does not change.

       Passing `none' for STYLE disables the setting from any
       `--build-id' options earlier on the command line.

I suppose Go uses one of md5 or sha1, which is a good thing since it
allows for reproducible builds.

However, grafting breaks this, similarly to <https://bugs.gnu.org/19973>
since they change file contents without recomputing the build ID.

Having Go use --build-id=uuid would work around the problem, but it
would also prevent bit-reproducible builds.

Perhaps our grafting code will have to handle .note.gnu.build-id
specially.

Thoughts?

Thanks for reporting the issue,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.