[MPlayer-dev-eng] [PATCH v2] configure: Avoid eh_frame bloat in release builds

[Reimar Döffinger]

On Sat, Feb 13, 2016 at 06:11:46PM +0200, Lauri Kasanen wrote:
> On Sat, 13 Feb 2016 16:53:17 +0100
> Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> 
> > > -fno-async provides the majority of the size benefit indeed, the
> > > difference was just bytes. Attaching v2.
> > 
> > I also suspect, as we are checking it to work anyway, that this
> > shouldn't be gnu only.
> > Seems reasonable to believe that other compilers might have the
> > same option.
> 
> Google says clang supports the option, but I cannot test that.

Applied with it moved out of the gcc-specific path.

> > > The few C++ files in mplayer and ffmpeg do not use exceptions
> > > (incidentally, -fno-exceptions and -fno-rtti should be added to
> > > CXXFLAGS, they have size impact as well).
> > 
> > To my knowledge, -fno-rtti changes ABI, and those C++ files are
> > mostly there to use C++ library (which might use RTTI and exceptions,
> > to the exceptions thing might not matter).
> > So I don't believe these options are safe to add.
> 
> Those options are quite safe when the code doesn't use the features.
> The C++ library's internals do not matter, it's made so that programs
> with and without rtti and exceptions work.

The C++ library maybe, but I am talking about other libraries that
have a C++-based API.
While it might work fine with gcc, to my knowledge there is no
guarantee that -fno-rtti in no case changes e.g. sizeof(MyClass).
Thus using -fno-rtti when linking to a (non-libstdc++) C++ library
that was compiled without does not seem safe at all.
There is also the issue a C++ library "leaking" an exception, if
it isn't caught it will still crash in the end, but in an application
compiled with -fno-exceptions I am not sure the results could be
worse (like not cleaning up stack-allocated objects even inside
the library).
Considering the pain it would be to debug, I still think it's
better to not optimize that far.
At least not while there is much lower hanging fruit.

> If this were a C++ library instead of a program, then they wouldn't be
> safe to add, in case a user of the library used the features.

I think in case of exceptions it's actually the other way around,
at least if it is a library without callbacks.