From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?G=C3=A1bor_Boskovits?= Subject: Re: gcc-ddc Date: Thu, 30 Nov 2017 15:32:07 +0100 Message-ID: References: <871skskduj.fsf@gnu.org> <87lgj0wqbd.fsf@elephly.net> <87mv3dv59h.fsf@elephly.net> <877eu9f56j.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113ecd3ae1505c055f341d2f" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53616) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eKPsz-0005WD-Ee for guix-devel@gnu.org; Thu, 30 Nov 2017 09:32:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eKPst-0002ta-L3 for guix-devel@gnu.org; Thu, 30 Nov 2017 09:32:21 -0500 In-Reply-To: <877eu9f56j.fsf@gnu.org> 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: Jan Nieuwenhuizen Cc: Guix-devel --001a113ecd3ae1505c055f341d2f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It seems, that the libtool file differences leak into the checksum. I will try to contact developers on how to bypass that issue. 2017-11-29 16:57 GMT+01:00 Jan Nieuwenhuizen : > G=C3=A1bor Boskovits writes: > > > It seems, that I can make really good progress here. > > Now the only things that remain: > > Great! > > > The libtool .la files record the installation directory, these are > textfile wrappers anyways, so I don't know if > > we should care about this. > > How about asking the libtool developers? > > > The mkheaders shell srcipt in install-tools record the installation > directory, this is in source form by the > > way, so I don't know if we should care about this. > > In a way similar to the libtool wrappers: the build is still > reproducible in a way; just harder to check with Guix. Having > everything below /gnu/store/deadbeef-gcc-4.7.4 identical could be a > feature, but possibly something left for later. > > > The only remainig problem is that the symbol executable_checksum in cc1 > and cc1plus still differ. No other > > differences remained. > > OK! > > > I'm now investigating the checksum issue. > > Great to hear your progress > janneke > -- > Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org > Freelance IT http://JoyofSource.com | Avatar=C2=AE http://AvatarAcademy.c= om > --001a113ecd3ae1505c055f341d2f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It seems, that the libtool file differences leak into the = checksum.
I will try to contact developers on how to bypass that issue.=


2017-11-29 16:57 GMT+01:00 Jan Nieuwenhuizen &l= t;janneke@gnu.org&= gt;:
G=C3=A1bor B= oskovits writes:

> It seems, that I can make really good progress here.
> Now the only things that remain:

Great!

> The libtool .la files record the installation directory, these are tex= tfile wrappers anyways, so I don't know if
> we should care about this.

How about asking the libtool developers?

> The mkheaders shell srcipt in install-tools record the installation di= rectory, this is in source form by the
> way, so I don't know if we should care about this.

In a way similar to the libtool wrappers: the build is still
reproducible in a way; just harder to check with Guix.=C2=A0 Having
everything below /gnu/store/deadbeef-gcc-4.7.4 identical could be a
feature, but possibly something left for later.

> The only remainig problem is that the symbol executable_checksum in cc= 1 and cc1plus still differ. No other
> differences remained.

OK!

> I'm now investigating the checksum issue.

Great to hear your progress
janneke
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar=C2=AE http://AvatarAcademy.c= om

--001a113ecd3ae1505c055f341d2f--