all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Hank Donnay <hdonnay@gmail.com>
Cc: 25752@debbugs.gnu.org
Subject: bug#25752: go incremental builds broken
Date: Tue, 07 Mar 2017 22:50:00 +0100	[thread overview]
Message-ID: <87fuiorc3b.fsf@gnu.org> (raw)
In-Reply-To: <CAD4UWkjnkSBYmAfk+E5QAvO9H29Y1xS2vu_h8eB3ZypJ=7NHwg@mail.gmail.com> (Hank Donnay's message of "Thu, 16 Feb 2017 10:05:27 -0500")

Hello,

Hank Donnay <hdonnay@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’.

      parent reply	other threads:[~2017-03-07 21:51 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-16 15:05 bug#25752: go incremental builds broken Hank Donnay
     [not found] ` <handler.25752.B.14872575426869.ack@debbugs.gnu.org>
2017-02-24 19:50   ` bug#25752: Acknowledgement (go incremental builds broken) Hank Donnay
2017-02-25 15:58     ` Leo Famulari
2020-12-18 20:00       ` zimoun
2020-12-18 21:31         ` Leo Famulari
2021-01-11 12:46           ` zimoun
2021-01-11 20:01             ` Efraim Flashner
2021-06-09 21:38               ` zimoun
2021-11-26  1:12               ` zimoun
2021-09-14 10:43           ` bug#25752: go incremental builds broken zimoun
2022-10-26 20:42             ` zimoun
2022-10-27 10:21               ` Maxime Devos
2022-10-28  8:22                 ` zimoun
2023-10-16 22:44                   ` Simon Tournier
2017-03-07 21:50 ` Ludovic Courtès [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fuiorc3b.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=25752@debbugs.gnu.org \
    --cc=hdonnay@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.