On Sat, May 26, 2007 at 06:14:46AM +0100, Oliver Elphick wrote:
> 1. Change the Makefile and/or debian/rules as necessary to add -g to the
> compilation options.
Most already do that.
> 2. In debian/rules, comment out the instruction to strip the binaries
> (such as dh_strip).
No, use the enviro
Oliver Block ha scritto:
> Hello list,
>
> I am not very familiar with the debian developer tools. How to recompile a
> package with debuggin option (gcc -g)?
usually packages are compiled with -g, but are stripped afterwards; to
avoid that, see example:
as root
# apt-get build-dep mplayer
# a
On Sat, 2007-05-26 at 06:14:46 +0100, Oliver Elphick wrote:
> On Sat, 2007-05-26 at 03:29 +0200, Oliver Block wrote:
> > I am not very familiar with the debian developer tools. How to
> > recompile a package with debuggin option (gcc -g)?
>
> 1. Change the Makefile and/or debian/rules as necessary
On Sat, 2007-05-26 at 03:29 +0200, Oliver Block wrote:
> Hello list,
>
> I am not very familiar with the debian developer tools. How to
> recompile a package with debuggin option (gcc -g)?
1. Change the Makefile and/or debian/rules as necessary to add -g to the
compilation options.
2. In debian/
Hello list,
I am not very familiar with the debian developer tools. How to recompile a
package with debuggin option (gcc -g)?
Thanks in advance.
Best Regards,
Oliver
I thought it might be worth pointing out that this has already been done
on a large scale, in Mac OS X. That is precisely why PPC and i386 gcc
are now largely fixed. Also, that the Mac OS team did considerable
testing, and now build almost everything with -Os.
I heard this at a presentation fr
On Sun, May 07, 2006 at 02:29:18PM -0300, Henrique de Moraes Holschuh wrote:
> Which have BIG caches, and thus might get sensible speedups if -Os manages
> to make the entire thing fit inside the cache (which it just might, I have
> seen non-exaustive reports of it working well for many people).
W
On Sat, 06 May 2006, Anthony DeRobertis wrote:
> older machines) but also with amd64 (which I doubt there are any 64mb
> AMD64 systems) and ia64 (which I very much doubt there are any 64mb
Which have BIG caches, and thus might get sensible speedups if -Os manages
to make the entire thing fit insid
On Sat, May 06, 2006 at 04:44:23PM +0200, Goswin von Brederlow wrote:
> Initialiy this was for people with older computers, not a 2 GHz amd64
> with 2GB ram. Think P90 with 64Mb or slightly better.
>
> We are not talking "generally" here but "specific". Specific to
> certain hardware.
OP mention
[Tried 'debian-user' with this question first, but there were no
responses. Now trying here. I'm not subscribed to 'debian-devel' so
please CC me if you respond!]
Original Message
Just out of curiosity, what is the Debian Way to change compiler
settings like -Ox and -march
On 5/3/06, Rogério Brito <[EMAIL PROTECTED]> wrote:
Just to see the effects of compiling programs with -Os, I tried to get
the sources for firefox 1.5 from testing (which is what I use by
default) and compiled it with -Os, instead of -O2. The program was much
more responsive, with less use of swa
Anthony DeRobertis <[EMAIL PROTECTED]> writes:
> On Wed, May 03, 2006 at 11:02:57AM -0300, Henrique de Moraes Holschuh wrote:
>
>> For Etch and Sid, it is probably a good idea to use -Os instead of -O2 at
>> least on the bigger arches (ia32, ia64, amd64, etc), as we can probably
>> trust gcc not t
Anthony DeRobertis wrote:
> On Wed, May 03, 2006 at 11:02:57AM -0300, Henrique de Moraes Holschuh wrote:
>
> > For Etch and Sid, it is probably a good idea to use -Os instead of -O2 at
> > least on the bigger arches (ia32, ia64, amd64, etc), as we can probably
> > trust gcc not to screw up.
>
> I
On Thu, May 04, 2006 at 11:54:44PM -0400, Anthony DeRobertis wrote:
> If gcc generally generates faster code with -Os than -O2, then isn't
> that a gcc bug, in that the optimizations enabled by -O2 are incorrectly
> picked?
The problem is, "faster" is not a well-defined term. Faster when? I can
w
On Fri, May 05, 2006 at 03:54:57AM +0200, Goswin von Brederlow wrote:
> "Joe Smith" <[EMAIL PROTECTED]> writes:
>> Wait a second. Optimizing for size should decrease speed.
>> That is the whole idea of size/speed optimization tradeoffs.
> A lot of the time the reduced ram requirement can stop swa
On Wed, May 03, 2006 at 11:02:57AM -0300, Henrique de Moraes Holschuh wrote:
> For Etch and Sid, it is probably a good idea to use -Os instead of -O2 at
> least on the bigger arches (ia32, ia64, amd64, etc), as we can probably
> trust gcc not to screw up.
If gcc generally generates faster code wi
"Joe Smith" <[EMAIL PROTECTED]> writes:
> "Rogério Brito" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> Hi there.
>
> I think that this may be interesting to anybody that has to work with
> computers that are not the latest/more recent as most people in richer
> countries seem to
"Rogério Brito" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Hi there.
I think that this may be interesting to anybody that has to work with
computers that are not the latest/more recent as most people in richer
countries seem to have.
It seems to be that a good amount of peopl
On Wed, 03 May 2006, Rogério Brito wrote:
> One way to mitigate the memory consumption is to, among other things,
> compile packages with optimization of GCC set to -Os, instead of -O2,
What -Os is likely to give you is much better cache locality, which might
make the code run that much faster on
Hi there.
I think that this may be interesting to anybody that has to work with
computers that are not the latest/more recent as most people in richer
countries seem to have.
It seems to be that a good amount of people upgrade their computers in a
regular basis and, then, don't notice how things
Guy Maor writes:
> > I'd suggest that all such packages only try to compile and package the
> > libc5 packages if there is a libc5 installed.
>
> No, that's a bad idea. A package might silently build incorrectly
> because a developer didn't have libc5 or libc5-dev installed.
>
> Unfortunately ha
Martin Schulze <[EMAIL PROTECTED]> writes:
> I'd suggest that all such packages only try to compile and package the
> libc5 packages if there is a libc5 installed.
No, that's a bad idea. A package might silently build incorrectly
because a developer didn't have libc5 or libc5-dev installed.
Unf
Good evening,
during compiling re-packaging of some libraries on the powerpc I
noticed several problems regarding our libc.
On the powerpc - as on the alpha - there is no libc5 package and will
never be (I guess). As a result compilation of any library that
provides both a libc5 and libc6 releas
23 matches
Mail list logo
