--enable-debug vs --enable-symbols (Re: [Libreoffice-commits] .: 12 commits - config_host.mk.in configure.in filter/source oox/source sal/inc sc/source solenv/gbuild toolkit/source xmlhelp/source)

[Lubos Lunak]

On Friday 18 of May 2012, Michael Stahl wrote:
> On 16/05/12 15:09, Lubos Lunak wrote:
> > these switches are actually supposed to do. As far as I can
> > tell, --enable-symbols enables -g, --enable-debug does --enable-symbols
> > and turns on logging+assertions and disables optimizations, and
> > --enable-dbgutils does --enable-symbols plus whatever extra stuff that is
> > BIC. That's indicentally also what --help says about them. What is your
> > idea about what these options do?
>
> so there are 3 options, and --enable-symbols differs from the other 2 in
> that it only adds symbols to the output, it does not enable any
> debugging feature, or assertion, it does not disable optimizations, and
> it is primarily used not by developers, but by distributors who want to
> be able to produce reliable stack traces for _product_ builds, e.g. the
> Fedora RPM spec file unconditionally sets --enable-symbols, these
> symbols are split out by some RPM magic into libreoffice-debuginfo
> package, and then ABRT reports useful stacks to rhbz.

 So if I understand this correctly, you also see --enable-symbols as a 
shorthand for -g in CXXFLAGS. Ok, so we agree on the big picture, now we need 
to figure out the details.

> (i wonder if -ggdb1 exists and would be sufficient for symbols but don't
> care enough to try).

 It does, from gcc manpage: "Level 1 produces minimal information, enough for 
making backtraces in parts of the program that you don't plan to debug.  This 
includes descriptions of functions and external variables, but no information 
about local variables and no line numbers."

> >  Now --enable-debug=-sc/ means that sc/ is built without -g and with -O2.
> > In other words, the compiler spends extra time working on code I don't
> > care about at all. There was a reason why OPT flags was empty in
> > --enable-debug build - as soon as I do a developer build, I don't want
> > the compiler to optimize any code, anywhere, unless explicitly told so.
>
> that is surprising; i had thought that developers either want code that
> runs fast, or code that is debuggable (i.e. the point of disabling
> optimizations is not to confuse the debugger), but you apparently want
> slow code that is not debuggable?

 I want code that builds fast. Or rather, code that doesn't take ages to 
build. LO needs a lot of time for building even without the compiler spending 
time on optimizing it. But I'm not actually thinking of me, I know I can 
manually override CXXFLAGS, I'm thinking of people who don't have as powerful 
build systems and have to wait a long time for builds. I think people are 
more likely to see big delays rather than many small ones.

> it has occasionally annoyed me how horribly slow loading certain large
> documents becomes if optimization is disabled.
>
> >  Moreover, such code actually is built also with -g. I'm not sure why,
> > but something now seems to turn on -g for everything, regardless of the
> > selective symbols.
>
> sounds like you also have --enable-symbols on, which works globally, as
> the intended target audience doesn't know for which parts stack traces
> need to be generated, so it doesn't make sense to sub-divide this.

 I don't, it's something else introducing it. But that's just a bug somewhere.

> >>     So move the selective symbol feature back to --enable-debug.
> >
> >  That does not make much sense. Even this very sentence says that symbols
> > and debug are again tangled together.
>
> makes sense, because it is in fact not a "selective symbol" but a
> "selective debug" feature (and iirc Bjoern had originally implemented it
> as such);

  But --enable-debug enables assertions, logging and other stuff, 
so --enable-debug=sc/ seems to suggest that they will be only enabled in 
sc/ , while in fact they will be enabled everywhere, and only -g will be 
enabled in sc/ . So it is "selective symbol" and not "selective debug", 
because it only controls -g and has since Bjoern's first version. Having this 
selectivity controlled by --enable-debug only adds to the confusion about 
what option actually does what.

-- 
 Lubos Lunak
 l.lunak at suse.cz