Ludovic Courtès writes:
> Did you choose 4.7 due to the fact that it’s the last C-only version?
At the reproducible builds summit we talked about “checkpoints” that we
want to achieve, i.e. points in the build graph that one can arrive at
one way or another (in this case via clang or via GCC) b
Hello!
Gábor Boskovits skribis:
> Before FOSDEM I decided to take another look at this.
> I have really good news, gcc 4.7.4 ddc on x86_64 is now reproducible using
> clang.
> Code can be found at: https://github.com/Boskovits/guix/tree/gcc-ddc.
Woow, quite an achievement!
To be
Hello!
Before FOSDEM I decided to take another look at this.
I have really good news, gcc 4.7.4 ddc on x86_64 is now reproducible using
clang.
Code can be found at: https://github.com/Boskovits/guix/tree/gcc-ddc.
How could we go on with this?
Now it is very experimental, and not conforming to
>> I guess I can do something like add an environment variable
>> GUIX_INSTALL_DIRECTORY, or something like that...
>
> What's different about GUIX_INSTALL_DIRECTORY than the usual: PREFIX?
The value of that variable would not be embedded in the binary. It is
looked up at runtime, so the binary
Ok, I will do that.
I can eliminate differences in the wrappers easily, then I will look into
the libtool patch.
It seems, that the la files are causing the checksum difference in cc1 and
cc1plus, because if I remove libraries from the checksum, then they agree.
I also checked the same things when
Gábor Boskovits writes:
> Aside from these libtool files we can now say, that this ddc project
> succeeded.
Wait... The libtool's .la files are now the only files that show any
difference, even when gcc is compiled into it's own prefix? That's amazing!!!
> I've contacted the libtool developers
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 some
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ábor Boskovits writes:
>
> > It seems, that I can make really good progress here.
> > Now the only things that remai
Gábor 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 libtoo
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 :
> Hello!
>
> It seems, that I can make really good progress
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 installat
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 n
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 wra
for these environment
> variables.
Ricardo, ideas?
> One thing we still miss, is that the gcc-ddc package does not produce output
> if the comparison is successful, so
> we have build failed then too.
> It would be great, if we could store the diffoscope output in a file in t
ling to do this with the wrapper, or at
least can point me to some packages already doing this.
I'd like some help with choosing appropriate names for these environment
variables.
One thing we still miss, is that the gcc-ddc package does not produce
output if the comparison is successful, so
Jan Nieuwenhuizen writes:
> Gábor Boskovits writes:
>
> Hey Gábor!
>
> [cc: guix-devel]
>
>> I'm definietly making progress on this. Now I have a working debug build of
>> gcc.
>> Identified the critical symbols, they are:
>
>> static const char *const standard_exec_prefix = STANDARD_EXEC_PREFI
Gábor Boskovits writes:
> I just pushed what I have right now. It's on branch gcc-ddc on my github.
> Should I post a patch here?
Great!
Yes, that makes commenting on it an easy option. Also, please mention
the location to clone from. github is non-free, but cloning from it
is o
I just pushed what I have right now. It's on branch gcc-ddc on my github.
Should I post a patch here?
2017-11-21 0:16 GMT+01:00 Gábor Boskovits :
> The only problematic one seems to be standard_libexec_prefix, because that
> is used in line 3654 of gcc/gcc.c in a real assignment.
&
The wrapper approach eliminated those three, we still have in prefix.c the
prefix used as static initializer. I have to investigate further, but it's
only 300 lines, should be tractable.
2017-11-21 0:16 GMT+01:00 Gábor Boskovits :
> The only problematic one seems to be standard_libexec_prefix, be
The only problematic one seems to be standard_libexec_prefix, because that
is used in line 3654 of gcc/gcc.c in a real assignment.
It is also used in line 64 of gcc/gcc-ar.c.
Other uses of all these other symbols could be calculated as compile time
realitve paths, and if we can live with these pa
Gábor Boskovits writes:
Hey Gábor!
[cc: guix-devel]
> I'm definietly making progress on this. Now I have a working debug build of
> gcc.
> Identified the critical symbols, they are:
> static const char *const standard_exec_prefix = STANDARD_EXEC_PREFIX;
> static const char *const standard_libe
21 matches
Mail list logo
