OK to get rid of scaddins?
michael.meeks at suse.com
Tue Feb 14 02:52:31 PST 2012
On Mon, 2012-02-13 at 16:06 +0100, Michael Stahl wrote:
> >> (of course i don't care if you do it for a special "merged libs" mode,
> >> but C++ development is already a sufficiently unproductive activity that
> >> we shouldn't make it even more so...)
> > Is it necessary to build with full debug enabled ? how slow is it
> > really ? [ if it takes ten minutes - how slow is it to re-build with
> > just the bits you want symbols for & re-run whatever you're
> > debugging ?].
> i find it works quite well with 8GB of RAM, except that linking takes
> much longer (and you better not have 3 unit tests crash concurrently
> otherwise gdb will lock up the box for 15 minutes until OOM killer is
So - can you give some concrete ideas of time & space it is taking to
link our shared libraries ? and also the growth in size that we get -
what is the stripped vs. non-stripped output ? Mark prolly has some
great insights as to how to improve that.
> > I wonder if the new 'gold' linker will help performance wise - have you
> > tried it ?
> no, but the problem is really the space that the object files take up:
> they don't fit all into RAM cache, and ld is blocked on I/O most of the
> time (in tail_build).
If we have > 8Gb of debug symbols per module there is a -real- problem
here; Lubos was talking of using some more magic / smaller debug option
in the past: -gdwarf-4
Are you using that ? I believe we turned it off by default again for
some reason or other: potentially we want to add a check for a tolerably
recent toolchain and debugger on the system before defaulting to that
[ it supposedly saved 30% of the size ], but you need gdb 7.3 really.
Either way, it sucks to hinder ourselves from creating a more efficient
library structure because of un-necessary performance problems in the
All the best,
michael.meeks at suse.com <><, Pseudo Engineer, itinerant idiot
More information about the LibreOffice