Re: gcc-ddc

["Gábor Boskovits" <boskovits@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2586 bytes --]

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ábor Boskovits <boskovits@gmail.com>:

> 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 should
> 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ábor Boskovits <boskovits@gmail.com>:
>
>> 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 <rekado@elephly.net>:
>>
>>>
>>> Hi Gábor,
>>>
>>> > 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’s sufficient already.  Since the result of this 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
>>> environment
>>> > variables.
>>>
>>> I would prefix all of the environment variables with “GUIX_GCC_” just to
>>> avoid conflicts with other legitimate environment variables.  Other than
>>> that the names are fine.
>>>
>>> Thanks for investigating this.  I’m impressed with your level of success!
>>>
>>> --
>>> Ricardo
>>>
>>> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
>>> https://elephly.net
>>>
>>>
>>>
>>
>

[-- Attachment #2: Type: text/html, Size: 4003 bytes --]