exception handling disabled, use -fexceptions to enable
Marco Cavallini
I am trying to build the latest CVS 2.5.1 in X11 mode
I get the following error but I don't understand what -fexceptions is.
<snip>
-DwxUSE_BASE=1 -fno-rtti -fno-exceptions -O2 -Wall src/common/init.cpp
src/common/init.cpp: In function `int wxEntry(int &, wxChar **)':
src/common/init.cpp:397: exception handling disabled, use -fexceptions to
enable
make[1]: *** [baselib_init.o] Error 1
This is my configuration:
--with-x11 --without-gtk --enable-no_rtti \
--disable-joystick \
--disable-mdi --disable-printarch --disable-postscript --disable-resources \
--disable-prologio --with-zlib=builtin --with-libpng=builtin \
--with-libjpeg=builtin --with-libtiff=builtin \
--disable-shared --enable-exceptions
I tried also playing with
--enable-no_exceptions --disable-threads --disable-sockets
But always I face to the same problem
Anybody could help me please ?
Ciao
Marco
Vadim Zeitlin
MC> I am trying to build the latest CVS 2.5.1 in X11 mode
MC> I get the following error but I don't understand what -fexceptions is.
MC>
MC> <snip>
MC> -DwxUSE_BASE=1 -fno-rtti -fno-exceptions -O2 -Wall src/common/init.cpp
You must have used --enable-no_exceptions, reconfigure with
--disable-no_exceptions.
Regards,
VZ
Ron
Just a quick note on this subject in case it hasn't occurred to others
yet, but gtk+ is not usually built with -fexceptions so any attempt to
throw across an event boundary (ie. where the stack would be unwound
through gtk) will proabably abort on that platform.
The same is likely true for any of the other c libs we link with,
so to be robust any possible exceptions need to be caught early enough
to avoid passing them through the C function calls.
I know wx doesn't throw (yet), but some of the ancillary libs (or
stdc++) might, so we do need to be careful about the placement of any
catches if they are to actually be useful.
cheers,
Ron
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wx-dev-un...@lists.wxwindows.org
> For additional commands, e-mail: wx-de...@lists.wxwindows.org
>
Ron
> On Fri, 10 Oct 2003 06:30:37 +0930 Ron <r...@debian.org> wrote:
>
> R> Just a quick note on this subject in case it hasn't occurred to others
> R> yet, but gtk+ is not usually built with -fexceptions so any attempt to
> R> throw across an event boundary (ie. where the stack would be unwound
> R> through gtk) will proabably abort on that platform.
>
> Hmm, are you sure about this? Under Windows you can mix code using
> exceptions and not using them perfectly well, it's just that dtors are not
> going to be called during stack unwinding for the code compiled without
> exceptions. Why should it abort?
Well you made me go test it again, just to be sure I was sure :-/ And
so yes, empirically I am sure. We saw problems with this last week in
some code Jill was working on (result, that code now makes far less use
of exceptions).
Simple test is to add:
try { throw 1; } catch (...) { printf( "ok\n" ); }
to the OnAbout handler in minimal. You'll see that works just fine.
Now remove the catch and leave wxEntryReal to catch it. You'll see
it aborts instead of being caught.
I found a thread previously from some gtkmm users that indicate
compiling gtk with -fexceptions really will fix this, (as the gcc docs
lead me to expect) but unless we can convince them (and possibly other C
lib authors) to do this by default its not really a good solution
(though its the best one in an ideal world inclusive of exceptions).
More pragmatically, we could add a try/catch around event dispatches,
since as long as the exception is caught before the stack unwinds into a
gtk function we are safe, but I'm not sure exactly how many places that
would require patching, or what the performance implications might be in
all cases.
As to why it aborts, presumably for the same reason Marco had problems
with C++ code compiled with -fno-exceptions -- the compiler just does
not output code to handle the stack unwinding at all. gcc docs say
-fno-exceptions is the default setting for C code.
All this was tested with gcc3.3.2 from current debian unstable and
wx2.5 from cvs as of a day or two ago.
Sad but apparently true...
Ron