[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#30820: Chunked store references in compiled code break grafting (aga
From: |
Mark H Weaver |
Subject: |
bug#30820: Chunked store references in compiled code break grafting (again) |
Date: |
Mon, 19 Mar 2018 15:16:30 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) |
Mark H Weaver <address@hidden> writes:
> address@hidden (Ludovic Courtès) writes:
>
>> The recently added glibc grafts triggered issues that, in the end, show
>> the return of <http://bugs.gnu.org/24703> (“Store references in 8-byte
>> chunks in compiled code”).
>
> I think that we should generalize our reference scanning and grafting
> code to support store references broken into pieces, as long as each
> piece containing part of the hash is at least 8 bytes long.
>
> Here's my preliminary proposal:
>
> (1) The reference scanner should recognize any 8-byte substring of a
> hash as a valid reference to that hash.
To facilitate the transition: to support older versions of the Guix
daemon (or Nix daemon), we could add a final phase to gnu-build-system
which would "unhide" these references as follows: It would scan each
output directory for 8-byte substrings of hashes. If it finds any
references that the old scanner is unable to see, it would install a
file to the output directory containing the full store names of the
hidden references.
This only works for output directories, though. I don't know what to do
about output files containing hidden references. I guess the final
phase should raise an error in this case, and hopefully it rarely
happens.
Mark
bug#30820: Chunked store references in compiled code break grafting (again), Mark H Weaver, 2018/03/19
bug#30820: Chunked store references in compiled code break grafting (again), Ludovic Courtès, 2018/03/19
bug#30820: Chunked store references in compiled code break grafting (again), Mark H Weaver, 2018/03/21