Re: [PATCH v2] configure: Avoid eh_frame bloat in release builds

Reimar Döffinger <[email protected]>
Newsgroups gmane.comp.video.mplayer.devel
Message-ID <[email protected]>
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 <[email protected]> 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.
_______________________________________________
MPlayer-dev-eng mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.