From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: diverse double compilation: using $ORIGIN? Date: Sat, 11 Nov 2017 22:56:13 +0100 Message-ID: <87bmk8fpj6.fsf@gnu.org> References: <87wp3agd60.fsf@elephly.net> <87bmkaray5.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54237) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eDdlG-0007s6-64 for guix-devel@gnu.org; Sat, 11 Nov 2017 16:56:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eDdlC-0006Z6-7t for guix-devel@gnu.org; Sat, 11 Nov 2017 16:56:22 -0500 Received: from hera.aquilenet.fr ([141.255.128.1]:40857) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eDdlC-0006Yp-0l for guix-devel@gnu.org; Sat, 11 Nov 2017 16:56:18 -0500 In-Reply-To: <87bmkaray5.fsf@gmail.com> (Chris Marusich's message of "Thu, 09 Nov 2017 20:53:38 -0800") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Chris Marusich Cc: guix-devel@gnu.org, bootstrappable@freelists.org Chris Marusich skribis: > Ricardo Wurmus writes: > >> Since the GCC build procedure is performed at least two >> times (once with the bootstrap compiler, and then again with the GCC >> variant this produces), the resulting GCC binaries should be identical. >> >> Except that they are not. One of the reasons is that the binaries >> that Guix produces embed the target output directories. This means >> that the two compiler binaries that result from diverse double >> compilation will *always* differ in at least the embedded paths, such >> as paths to itself (e.g. to binaries in the libexec directory) and >> paths to. > > What ever happened to the intensional model (i.e., a content-addressed > store)? If derivation outputs were content-addressed, this would not be > a problem, right? Indeed. > Dolstra's thesis presented some ideas for how to rewrite self-references > in derivation outputs under the intensional model. I've casually looked > into what happened with the intensional model since his thesis was > written, but I don't really know why it hasn't been implemented. All I > know is that Dolstra and the Nix devs seem to have moved away from that > idea; I never really learned the reason(s) why. One problem is that it requires 100% reproducible builds; if something doesn=E2=80=99t build reproducibly, you cannot get substitutes. Another problem is=E2=80=A6 migration. :-) Now, fixed-output derivations are one way to retrofit bits of the intensional model in the extensional model. Perhaps we could do more in that direction? Ludo=E2=80=99.