From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?G=C3=A1bor_Boskovits?= Subject: Re: gcc-ddc Date: Wed, 29 Nov 2017 13:26:50 +0100 Message-ID: References: <871skskduj.fsf@gnu.org> <87lgj0wqbd.fsf@elephly.net> <87mv3dv59h.fsf@elephly.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="94eb2c0b9c9c079dc9055f1e40a2" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58679) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eK1S8-0002qe-G5 for guix-devel@gnu.org; Wed, 29 Nov 2017 07:27:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eK1S7-00006o-1u for guix-devel@gnu.org; Wed, 29 Nov 2017 07:27:00 -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: Ricardo Wurmus Cc: Guix-devel --94eb2c0b9c9c079dc9055f1e40a2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Oops, I missed one. we have libstdc++.so.6.0.17-gdb.py, which is similar to the first two cases above, records installation diretory, in source form, I don't think we have to fix that either. 2017-11-29 10:43 GMT+01:00 G=C3=A1bor Boskovits : > Hello! > > It seems, that I can make really good progress here. > Now the only things that remain: > > The libtool .la files record the installation directory, these are > textfile wrappers anyways, so I don't know if we should care about this. > 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 shoul= d > care about this. > > I this two cases the transformation to get the other set of files is > simply to replace the prefix, so we could make a test on that if we want. > > The only remainig problem is that the symbol executable_checksum in cc1 > and cc1plus still differ. No other differences remained. > > I'm now investigating the checksum issue. > > 2017-11-23 12:23 GMT+01:00 G=C3=A1bor Boskovits : > >> Hello! >> >> It seems, that one of the source of the reporoducibilty issues with the >> gcc build output is that it contains la files with libdir recorded. >> Libtool records that in those la files. >> I wonder if we have any solution to that already, because it seems to >> affect every project using libtool. >> >> If not, do we have any idea to solve this? It would be great if we could >> come up with some generic solution to the problem. >> >> 2017-11-23 8:14 GMT+01:00 Ricardo Wurmus : >> >>> >>> Hi G=C3=A1bor, >>> >>> > I'm using the getenv approach Ricardo suggested. I've not written a >>> wrapper >>> > yet, the environment variables are set from the build. >>> >>> Maybe that=E2=80=99s sufficient already. Since the result of this pack= age is >>> not going to be used as an input to build software it may not actually >>> need a wrapper. >>> >>> Instead we can just set the variables in a build phase. >>> >>> > I'd like some help with choosing appropriate names for these >>> environment >>> > variables. >>> >>> I would prefix all of the environment variables with =E2=80=9CGUIX_GCC_= =E2=80=9D just to >>> avoid conflicts with other legitimate environment variables. Other tha= n >>> that the names are fine. >>> >>> Thanks for investigating this. I=E2=80=99m impressed with your level o= f success! >>> >>> -- >>> Ricardo >>> >>> GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC >>> https://elephly.net >>> >>> >>> >> > --94eb2c0b9c9c079dc9055f1e40a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Oops, I missed one. we have=C2=A0=C2=A0libstdc++.so.6.0.17-gdb.py, which is similar to the = first two cases above, records installation diretory, in source form, I don= 't think we have to fix that either.
2017-11-29 10:43 GMT+01:00 G=C3=A1bor Boskovit= s <boskovits@gmail.com>:
Hello!

It seems, that I can make reall= y good progress here.
Now the only things that remain:
=
The libtool .la files record the installation directory, the= se are textfile wrappers anyways, so I don't know if we should care abo= ut this.
The mkheaders shell srcipt in install-tools record the i= nstallation directory, this is in source form by the way, so I don't kn= ow if we should care about this.

I this two cases = the transformation to get the other set of files is simply to replace the p= refix, so we could make a test on that if we want.

The only remainig problem is that the symbol executable_checksum in cc1 an= d cc1plus still differ. No other differences remained.

=
I'm now investigating the checksum issue.

2017-11-23 12:23 GMT+01:00 G=C3=A1bor Boskovits <boskovits@gma= il.com>:
H= ello!

It seems, that one of the source of the reporoduci= bilty issues with the gcc build output is that it contains la files with li= bdir recorded.
Libtool records that in those la files.
= I wonder if we have any solution to that already, because it seems to affec= t every project using libtool.

If not, do we have = any idea to solve this? It would be great if we could come up with some gen= eric solution to the problem.

2017-11-23 8:14 GMT+01:00 Ricardo Wurmus <= span dir=3D"ltr"><rekado@elephly.net>:

Hi G=C3=A1bor,

> I'm using the getenv approach Ricardo suggested. I've not writ= ten a wrapper
> yet, the environment variables are set from the build.

Maybe that=E2=80=99s sufficient already.=C2=A0 Since the result of t= his package is
not going to be used as an input to build software it may not actually
need a wrapper.

Instead we can just set the variables in a build phase.

> I'd like some help with choosing appropriate names for these envir= onment
> variables.

I would prefix all of the environment variables with =E2=80=9CGUIX_G= CC_=E2=80=9D just to
avoid conflicts with other legitimate environment variables.=C2=A0 Other th= an
that the names are fine.

Thanks for investigating this.=C2=A0 I=E2=80=99m impressed with your level = of success!

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6=C2=A0 2150 197A 5888 235F ACAC
https:= //elephly.net





--94eb2c0b9c9c079dc9055f1e40a2--