From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?G=C3=A1bor_Boskovits?= Subject: Re: gcc-ddc Date: Thu, 23 Nov 2017 12:23:32 +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="001a1144f6c69516c9055ea4aab0" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:38064) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eHpbV-000305-7Q for guix-devel@gnu.org; Thu, 23 Nov 2017 06:23:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eHpbU-000879-4Q for guix-devel@gnu.org; Thu, 23 Nov 2017 06:23:37 -0500 In-Reply-To: <87mv3dv59h.fsf@elephly.net> 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 --001a1144f6c69516c9055ea4aab0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 packag= e 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 environmen= t > > 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 than > that the names are fine. > > Thanks for investigating this. I=E2=80=99m impressed with your level of = success! > > -- > Ricardo > > GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC > https://elephly.net > > > --001a1144f6c69516c9055ea4aab0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello!

It seems, that one of the source= of the reporoducibilty issues with the gcc build output is that it contain= s 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.

I= f not, do we have any idea to solve this? It would be great if we could com= e up with some generic solution to the problem.

2017-11-23 8:14 GMT+01:00 Ricardo= Wurmus <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



--001a1144f6c69516c9055ea4aab0--