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