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 05:40:34PM +0200, Lauri Kasanen wrote: > On Sat, 13 Feb 2016 16:26:42 +0100 > Reimar Döffinger <[email protected]> wrote: > > > On Sat, Feb 13, 2016 at 05:03:17PM +0200, Lauri Kasanen wrote: > > > Hi, > > > > > > This patch reduces both mplayer and mencoder size by 1mb, or 6%. The > > > eh_frame sections are mainly used for C++ exceptions and accurate > > > debugging, neither of which is desired in a C program and a release > > > build. > > > > To the best of my information, at the very least > > -fno-asynchronous-unwind-tables has no effect on debuggability > > if debug info is present. > > Thus is it should be set always. > > Did you check whether -fno-unwind-tables has any effect at all? > > I think this one is potentially not completely safe (we do have > > C++ code) and it would be better to not add it unless it really > > provides a significant benefit. > > -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. > 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. _______________________________________________ MPlayer-dev-eng mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng