[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: reproducible builds and debugging information
From: |
Ludovic Courtès |
Subject: |
Re: reproducible builds and debugging information |
Date: |
Thu, 26 Mar 2015 22:21:35 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) |
Tomáš Čech <address@hidden> skribis:
> On Tue, Mar 24, 2015 at 10:09:50PM +0100, Ludovic Courtès wrote:
[...]
>>Packages that have an autoconf-based build system, and I suppose most
>>others, are built with -g.
>
> I can't confirm this statement.
>
> I added "debug" output to curl package:
Indeed, I just checked and cURL overrides the default behavior. Here it
has to be configured with --enable-debug, which also enables the test
suite (!). Do you want to try that, and add the “debug” output?
>>The binaries get stripped by default and
>>debugging info is lost unless the package has a “debug” output.
>
> OK, the difference -g and -ggdb is slight, but there is the problem
> with "debug" output.
>
> When package has output "debug" always - there is no problem.
>
> When package doesn't have "debug" output and I need it, mere adding
> output "debug" into package receipt will change the hash so I'll get
> different package.
Right.
>>Currently a few key packages have that, but most don’t (I think Debian
>>does something similar, not sure about other distros.)
>
> On openSUSE you have available all the subpackage providing stripped
> debug informations and subpackage providing source code from the
> moment of build (so DWARF information in debug part can match the source).
You mean there’s a ‘-debug’ package for every single package?
>>We could make it opt-out rather than opt-in, but the issue is disk usage
>>on build machine (including end-user machines.) See
>><http://lists.gnu.org/archive/html/bug-guix/2013-07/msg00015.html>.
>>
>>Thoughts?
>
> If we have distribution of reproducible packages, we can keep it
> opt-in and generate debug information next time (by not dropping
> it).
That’s not how it works; generating the debug info requires redoing the
whole build process, but with a slight difference.
> The only problematic packages will be the big ones like Webkit, Libre
> Office and similar because generating debug increases memory usage
> during the build significantly and may not be suitable for average
> personal computer.
A problem for C++ code in general.
So again, we could make “debug” opt-out by default, but that’ll be some
work because of issues like this.
What do people think?
Thanks,
Ludo’.
- reproducible builds and debugging information, Tomáš Čech, 2015/03/22
- Re: reproducible builds and debugging information, Ludovic Courtès, 2015/03/24
- Re: reproducible builds and debugging information, Tomáš Čech, 2015/03/24
- Re: reproducible builds and debugging information,
Ludovic Courtès <=
- Re: reproducible builds and debugging information, Tomáš Čech, 2015/03/26
- Re: reproducible builds and debugging information, Ludovic Courtès, 2015/03/27
- Re: reproducible builds and debugging information, Tomáš Čech, 2015/03/27
- Re: reproducible builds and debugging information, Ludovic Courtès, 2015/03/28
- Re: reproducible builds and debugging information, Mark H Weaver, 2015/03/29
- Re: reproducible builds and debugging information, Ludovic Courtès, 2015/03/30