Re: ENABLE_SYMBOLS=true does nothing

On Tuesday 30 of October 2012, Markus Mohrhard wrote:
> 2012/10/30 Kohei Yoshida <kohei.yoshida@gmail.com>:
> > On 10/30/2012 05:27 PM, Lubos Lunak wrote:
> > >   make CFLAGS='-O -g' CXXFLAGS='-O -g' LDFLAGS=''
> > >
> > >   If that doesn't work then I need to fix it.
> >
> > Well, the idea is to *just* add -g to the flags without modifying any
> > other flags, and *just* remove -Wl,-S from LDFLAGS without removing other
> > flags. Changing other flags will change the generated binaries which may
> > affect reproducibility of certain bugs and/or performance profile of the
> > executable, and I'd like to avoid that (if we can).

 Explicit CXXFLAGS etc. override only gbuild's options related to -O and -g, 
nothing else, so if the default build goes with -Os, 'make CXXFLAGS=-Os' 
doesn't make any difference, and 'make CXXFLAGS="-Os -g"' does what 
ENABLE_SYMBOLS=true used to do. You can even pass CXXFLAGS=-Os to configure 
if you want to be 100% sure.

 And I have fixed the unwanted -Wl,-S if explicit CXXFLAGS is given, so this 
should now work.

> I have to agree with Kohei. The enable symbol option was the best and
> only way to get a build that you could use to profile calc.
>
> To get useful profile runs it was necessary to compile with
> optimization because of the heavy template use inside calc (mdds, ...)
>
> Are there any plans to provide a similar option again?

 I don't know about the 'only', but the important word there is 'was'. Do you 
really need it, given what I wrote above? The --enable-symbols/debug/dbgutil 
options were a source of repeated confusion, so when trying to put some sense 
into them about what they do exactly, and with the story being 
that --enable-symbols was only for packagers who explicitly give CXXFLAGS 
anyway, part of the outcome was to make CXXFLAGS work directly, 
drop --enable-symbols to reduce the confusion and turn it into the new 
clearly named --enable-selective-debuginfo for the somewhat niche scenario. 
I'd prefer to not bring it back because of a special use case that's already 
easily doable as it is.

-- 
 Lubos Lunak
 l.lunak@suse.cz