From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?G=C3=A1bor_Boskovits?= Subject: Re: gcc-ddc Date: Fri, 1 Dec 2017 16:44:54 +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="001a1144af5e1047f6055f4940d2" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:47096) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eKnWj-0000EF-N8 for guix-devel@gnu.org; Fri, 01 Dec 2017 10:47:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eKnVk-0006XS-Md for guix-devel@gnu.org; Fri, 01 Dec 2017 10:46:57 -0500 In-Reply-To: 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 --001a1144af5e1047f6055f4940d2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Aside from these libtool files we can now say, that this ddc project succeeded. I've contacted the libtool developers if we can extend the wrapper approach to the .la files. It seems, that in some older version of libtool those were just sourced as shell script, but I don't know if now they do something more fancy with it or not... Anyways, if it's just shell script, then the environment variable approach can also work out there. The only problem seems, that I should do the substitution before checksumming the compiler. I think I can inject something into the makefile, or use a patched vesion of libtool. A patched libtool could be a better option, so other ddc projects can use it. I guess I can do something like add an environment variable GUIX_INSTALL_DIRECTORY, or something like that... Any maybe name this version libtool-for-ddc. It should be noted in the package documentation, that this package is not recommended for general use. WDYT? 2017-11-30 15:32 GMT+01:00 G=C3=A1bor Boskovits : > 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 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 | GNU LilyPond http://lilypond.org >> Freelance IT http://JoyofSource.com | Avatar=C2=AE http://AvatarAcademy.= com >> > > --001a1144af5e1047f6055f4940d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Aside from these libtool files we can now say, that this d= dc project succeeded.
I've contacted the libtool developers if we c= an extend the wrapper approach to the .la files.
It seems, that i= n some older version of libtool those were just sourced as shell script, bu= t
I don't know if now they do something more fancy with it or= not...
Anyways, if it's just shell script, then the environm= ent variable approach can also work out there.
The only problem s= eems, that I should do the substitution before checksumming the compiler.
I think I can inject something into the makefile, or use a patched= vesion of libtool.

A patched libtool could be a b= etter option, so other ddc projects can use it.
I guess I can do = something like add an environment variable GUIX_INSTALL_DIRECTORY, or somet= hing like that...
Any maybe name this version libtool-for-ddc.
It should be noted in the package documentation, that this package = is not recommended for general use.

WDYT?
=C2=A0

2017-11-30 15:32 GMT+01:00 G=C3=A1bor Boskovits <boskovits@gmail.com<= /a>>:
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 <janne= ke@gnu.org>:
G=C3=A1b= or 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 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


--001a1144af5e1047f6055f4940d2--