On Thu, May 12, 2011 at 08:55:32AM -0700, John Reiser wrote:
> >>> FWIW this is a matter of 227Mb large /usr/lib/valgrind versus 71Mb without
> >>> debug.
> >>
> >> Which machine architecture and compiler?
> >
> > amd64 gcc, but indeed with -g, because it's how binaries are supposed to
> > be buil
>>> FWIW this is a matter of 227Mb large /usr/lib/valgrind versus 71Mb without
>>> debug.
>>
>> Which machine architecture and compiler?
>
> amd64 gcc, but indeed with -g, because it's how binaries are supposed to
> be built in Debian.
For many [most?] packages, Fedora handles this by building _w
On Thu, May 12, 2011 at 07:58:14AM -0700, John Reiser wrote:
> > Hi, in the packaging readme[0] for valgrind it's stated that it's a bad
> > idea to strip what's in /usr/lib/valgrind/ ...
>
> > FWIW this is a matter of 227Mb large /usr/lib/valgrind versus 71Mb without
> > debug.
>
> Which machine
> Hi, in the packaging readme[0] for valgrind it's stated that it's a bad
> idea to strip what's in /usr/lib/valgrind/ ...
> FWIW this is a matter of 227Mb large /usr/lib/valgrind versus 71Mb without
> debug.
Which machine architecture and compiler?
There's a difference between stripped (applyin
Hi, in the packaging readme[0] for valgrind it's stated that it's a bad
idea to strip what's in /usr/lib/valgrind/ because it makes bad reports.
Though if I test, here is what I get:
unstripped:
┌─(13:43)
└[apollon] valgrind ./a
==20112== Memcheck, a memory error detector
==20
