Removing -fexceptions from $RPM_OPT_FLAGS

[Pierre-Yves Chibon]

Hi,

I have been looking into the review #668863 in which the packager for
this library (who also happens to be upstream) is actually removing the
flag "-fexceptions" from $RPM_OPT_FLAGS in the %build.

Asking this question on irc (on fedora-devel) as lead to a small
discussion without clear agreement.

Unfortunately, my knowledge of C++ is not sufficient for me to take a
decision and I therefore would like to know if this would be a blocker
for the review.

I have to say:
- The package compiles with and without the flag
- Upstream does not want to have this flag on, saying that if an
exception occurs the program should crash anyway (that is its expected
behavior)*.

Thanks for your help,

Pierre


* That is if I understood correctly.

[Frank Ch. Eigler]

Pierre-Yves <pingou(a)pingoured.fr&gt; writes:

>  [...]
>  I have been looking into the review #668863 in which the packager for
>  this library (who also happens to be upstream) is actually removing the
>  flag "-fexceptions" from $RPM_OPT_FLAGS in the %build.
>  [...] 
>  - Upstream does not want to have this flag on, saying that if an
>  exception occurs the program should crash anyway (that is its expected
>  behavior)*. 
-fexception allows a C library to participate in C++ exception
handling.  It does not cost anything except extra data tables in the
ELF file.  Its presence matters in cases where a C library is used by
a C++ program, for example where the library may make a callback into
the C++ program, and that callback might throw an exception.  With
-fexception, that exception will be propagated properly through the C
library, to the outermost application.  Without it, exceptions thrown
from a callback may abort the program, even if the overall application
wanted to catch it.

If the C library does not have callbacks, then this particular reason
may not apply, but others might.  -fexception should be kept.

- FChE


`-fexceptions'
     Enable exception handling.  Generates extra code needed to
     propagate exceptions.  For some targets, this implies GCC will
     generate frame unwind information for all functions, which can
     produce significant data size overhead, although it does not
     affect execution.  If you do not specify this option, GCC will
     enable it by default for languages like C++ which normally require
     exception handling, and disable it for languages like C that do
     not normally require it.  However, you may need to enable this
     option when compiling C code that needs to interoperate properly
     with exception handlers written in C++.  You may also wish to
     disable this option if you are compiling older C++ programs that
     don't use exception handling.

[Jakub Jelinek]

On Tue, Jan 18, 2011 at 06:08:37PM -0500, Frank Ch. Eigler wrote:
>  -fexception allows a C library to participate in C++ exception
>  handling.  It does not cost anything except extra data tables in the
>  ELF file.  Its presence matters in cases where a C library is used by
>  a C++ program, for example where the library may make a callback into
>  the C++ program, and that callback might throw an exception.  With
>  -fexception, that exception will be propagated properly through the C
>  library, to the outermost application.  Without it, exceptions thrown
>  from a callback may abort the program, even if the overall application
>  wanted to catch it. 
-fexceptions is also desirable for POSIX thread cancellation.

	Jakub

[William Lima]

so, -fexception is mandatory for building C++ libraries @ Fedora?


-- 
w

[Haïkel Guémar]

hi,

after a good night of sleep, i just noticed that *just* removing the
-fexceptions flag won't change anything.
-fexceptions is for C code linking to C++ code, but it's already default
when compiling C++, then you have to use the -fno-exceptions flag
instead if you really want to disable that feature.

Besides, what happens if the standard library (or another underlying
library) throws an exception ? -fno-exceptions is for embedded guys that
already disabled the whole exception feature, not for generalistic
systems like Fedora.

Morale: that's just *PLAIN USELESS* to only remove the -fexceptions from
flags, anyway, it's already there. And sleeping might be a good thing.

best regards,
H.

[Matej Cepl]

Dne 19.1.2011 07:53, Haïkel Guémar napsal(a):
>  Morale: that's just *PLAIN USELESS* to only remove the
> -fexceptions from
>  flags, anyway, it's already there. And sleeping might be a good thing. 
+1 for a good example of disaster which IMHO happens see
https://bugzilla.mozilla.org/show_bug.cgi?id=512190.

Matěj

[William Lima]

On Wed, Jan 19, 2011 at 4:53 AM, Haïkel Guémar <karlthered(a)gmail.com&gt; wrote:
>  hi,
>
>  after a good night of sleep, i just noticed that *just* removing the
>  -fexceptions flag won't change anything.
>  -fexceptions is for C code linking to C++ code, but it's already default
>  when compiling C++, then you have to use the -fno-exceptions flag
>  instead if you really want to disable that feature. 
it was disabled since I use '-fno-exceptions' in Makefile.

>  Besides, what happens if the standard library (or another underlying
>  library) throws an exception ? -fno-exceptions is for embedded guys that
>  already disabled the whole exception feature, not for generalistic
>  systems like Fedora. 
crash (e.g. alloc).

>  Morale: that's just *PLAIN USELESS* to only remove the
> -fexceptions from
>  flags, anyway, it's already there. And sleeping might be a good thing. 
Indeed, if exceptions are mandatory in Fedora I will enable it.


-- 
w

[Tom Lane]

Hmm ... so what should I do with mysql?  Since approximately forever,
upstream has recommended using -fno-exceptions (and also
-felide-constructors -fno-rtti) in CXXFLAGS.  I now realize that it's
a bit silly to do that when the plain-C files (of which there are
plenty) are being built with -fexceptions because of Fedora's standard
RPM_OPT_FLAGS.  I also note that the recommendation to do that seems to
have disappeared from their manual as of mysql 5.5 ... although their
own RPM specfile is still doing it.

Seems like I should either drop the nonstandard CXXFLAGS, or hack CFLAGS
to remove -fexceptions.

			regards, tom lane

[Frank Ch. Eigler]

Tom Lane <tgl(a)redhat.com&gt; writes:

>  Hmm ... so what should I do with mysql?  Since approximately
> forever,
>  upstream has recommended using -fno-exceptions (and also
>  -felide-constructors -fno-rtti) in CXXFLAGS.  [...] 
-fexceptions / -frtti are essentially harmless, so I am curious why
they were ever thought to be undesirable.  -felide-constructors might
have worked around some gcc bug perhaps, but it must not be an issue
any more.

>  Seems like I should either drop the nonstandard CXXFLAGS, or hack
> CFLAGS
>  to remove -fexceptions. 
I suggest the former, especially without better rationale.

- FChE

[Tom Lane]

fche(a)redhat.com (Frank Ch. Eigler) writes:
>  Tom Lane <tgl(a)redhat.com&gt; writes:
> > Hmm ... so what should I do with mysql?  Since approximately forever,
> > upstream has recommended using -fno-exceptions (and also
> > -felide-constructors -fno-rtti) in CXXFLAGS.  [...]
> > ...
> > Seems like I should either drop the nonstandard CXXFLAGS, or hack CFLAGS
> > to remove -fexceptions. 
>  I suggest the former, especially without better rationale. 
Well, it passes its regression tests without these flags; so as soon as
the systemtap dust settles, I'll run a new rawhide build.

			regards, tom lane

[Kevin Kofler]

Tom Lane wrote:
>  Hmm ... so what should I do with mysql?  Since approximately
> forever,
>  upstream has recommended using -fno-exceptions (and also
>  -felide-constructors -fno-rtti) in CXXFLAGS.  I now realize that it's
>  a bit silly to do that when the plain-C files (of which there are
>  plenty) are being built with -fexceptions because of Fedora's standard
>  RPM_OPT_FLAGS.  I also note that the recommendation to do that seems to
>  have disappeared from their manual as of mysql 5.5 ... although their
>  own RPM specfile is still doing it.
>  
>  Seems like I should either drop the nonstandard CXXFLAGS, or hack CFLAGS
>  to remove -fexceptions. 
FWIW, exactly the same thing is happening in all of KDE, and everything 
building against kdelibs-devel using CMake (unless the package adds the 
KDE4_ENABLE_EXCEPTIONS macro to its compiler flags). FindKDE4Internal.cmake 
sets -fno-exceptions for C++, but not for C, so -fexceptions gets set for C 
files and -fno-exceptions for C++ files.

We may want to drop the "-fno-exceptions -DQT_NO_EXCEPTIONS" from the 
default CMAKE_CXX_FLAGS (or maybe add -fno-exceptions to the CMAKE_C_FLAGS). 
(Qt is already built with exception support these days because QtWebKit 
requires it. qt3/kdelibs3 is yet another can of worms, of course.)

        Kevin Kofler