Bug 75744 - InSimple KDE Aplication handling of exceptions is disabled
Summary: InSimple KDE Aplication handling of exceptions is disabled
Status: RESOLVED INTENTIONAL
Alias: None
Product: kdevplatform
Classification: Developer tools
Component: appwizard (show other bugs)
Version: 1.0.0
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: kdevelop-bugs-null
URL:
Keywords:
: 93115 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-02-21 01:01 UTC by Dmitry Selin
Modified: 2009-01-22 23:38 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitry Selin 2004-02-21 01:01:40 UTC
Version:           3.0.0 (using KDE 3.2.0, compiled sources)
Compiler:          gcc version 3.2.3
OS:          Linux (i686) release 2.4.22

Every time I create a new Simple KDE Aplication in KDevelop, I met a problem: handling of exceptions is disabled, and i can't enable it.
Comment 1 Arne Plöse 2004-05-13 22:17:22 UTC
the files "admin/acinclude.m4.in" or "admin/libtool.m4.in" seems to declare the compiler flag "-fno-exception" which can't be unset during configure run. At last it then popup in the Makefile.

If you add the compilerflag "-fno-exception" at "Project=>Project Options=>Configure Options=>C++" Compiler flags (CXXFLAGS), the named flag will appear twice.
Comment 2 Steven T. Hatton 2004-08-23 05:28:12 UTC
If anybody knows how to correct this situation, please, please, do so!

I sent this to the mailing list, but it may actually be more useful here:
On Saturday 21 August 2004 08:14, Steven T. Hatton wrote:
> http://www.kdevelop.org/HEAD/doc/api/html/gccoptionsplugin_8cpp-source.html
>
> I hit the above linked file while grepping the source tree for
> 'no-exception'. It looks like code to provide me with an options list to
> control compiler functionality, but I don't see the widget anywhere in
> KDevelop.  Grepping the source doesn't reveal any information about what
> might be using it.  It is clearly compiled, but It doesn't seem to do
> anything.
>
> Any ideas as to what it is?

I found the following in 
/download/org/kdevelop/repository/root/kdevelop/parts/appwizard/common/admin/libtool.m4.in 
on line 2671:

# We don't want -fno-exception wen compiling C++ code, so set the
# no_builtin_flag separately
if test "$GXX" = yes; then
  _LT_AC_TAGVAR(lt_prog_compiler_no_builtin_flag, $1)=' -fno-builtin'
else
  _LT_AC_TAGVAR(lt_prog_compiler_no_builtin_flag, $1)=
fi

That makes me believe the intention was to enable exception handling.

################################3


Then on line 4290, I find:


# AC_LIBTOOL_PROG_COMPILER_NO_RTTI([TAGNAME])
# -------------------------------------------
AC_DEFUN([AC_LIBTOOL_PROG_COMPILER_NO_RTTI],
[AC_REQUIRE([_LT_AC_SYS_COMPILER])dnl

_LT_AC_TAGVAR(lt_prog_compiler_no_builtin_flag, $1)=

if test "$GCC" = yes; then
  _LT_AC_TAGVAR(lt_prog_compiler_no_builtin_flag, $1)=' -fno-builtin'

  AC_LIBTOOL_COMPILER_OPTION([if $compiler supports -fno-rtti 
-fno-exceptions],
    lt_cv_prog_compiler_rtti_exceptions,
    [-fno-rtti -fno-exceptions], [],
    [_LT_AC_TAGVAR(lt_prog_compiler_no_builtin_flag, 
$1)="$_LT_AC_TAGVAR(lt_prog_compiler_no_builtin_flag, $1) -fno-rtti 
-fno-exceptions"])
fi
])# AC_LIBTOOL_PROG_COMPILER_NO_RTTI

Which I read to say: "If you are using GCC set -fno-exceptions."

####################################


Then on line 2791 of acinclude.in in the same directory I find:

dnl AC_VALIDIFY_CXXFLAGS checks for forbidden flags the user may have given
AC_DEFUN([AC_VALIDIFY_CXXFLAGS],
[dnl
if test "x$kde_use_qt_emb" != "xyes"; then
 AC_REMOVE_FORBIDDEN(CXX, [-fno-rtti -rpath])
 AC_REMOVE_FORBIDDEN(CXXFLAGS, [-fno-rtti -rpath])
else
 AC_REMOVE_FORBIDDEN(CXX, [-rpath])
 AC_REMOVE_FORBIDDEN(CXXFLAGS, [-rpath])
fi
])


Which looks like it is intended to explicitly prevent the user from setting 
-fno-exceptions and -fno-rtti:

############################################

Then on line 2952 of the same acinclude.in, I find:
  
  if test "$GXX" = "yes"; then
    KDE_CHECK_COMPILER_FLAG(fno-exceptions,[CXXFLAGS="$CXXFLAGS 
-fno-exceptions"])
    KDE_CHECK_COMPILER_FLAG(fno-check-new, [CXXFLAGS="$CXXFLAGS 
-fno-check-new"])
    KDE_CHECK_COMPILER_FLAG(fno-common, [CXXFLAGS="$CXXFLAGS -fno-common"])
    KDE_CHECK_COMPILER_FLAG(fexceptions, [USE_EXCEPTIONS="-fexceptions"], 
USE_EXCEPTIONS= )
  fi
  if test "$CXX" = "KCC"; then
    dnl unfortunately we currently cannot disable exception support in KCC
    dnl because doing so is binary incompatible and Qt by default links with 
exceptions :-(
    dnl KDE_CHECK_COMPILER_FLAG(-no_exceptions,[CXXFLAGS="$CXXFLAGS 
--no_exceptions"])
    dnl KDE_CHECK_COMPILER_FLAG(-exceptions, [USE_EXCEPTIONS="--exceptions"], 
USE_EXCEPTIONS= )

Which looks like someone has a different opinion about -fno-exceptions



################################################

Then this on line 4157 looks like the sed is trying to remove -fno-exceptions:
AC_DEFUN([KDE_CHECK_STL],
[
    AC_LANG_SAVE
    AC_LANG_CPLUSPLUS
    ac_save_CXXFLAGS="$CXXFLAGS"
    CXXFLAGS="`echo $CXXFLAGS | sed s/-fno-exceptions//`"

    AC_MSG_CHECKING([if C++ programs can be compiled])
    AC_CACHE_VAL(kde_cv_stl_works,
    [
      AC_TRY_COMPILE([
#include <string>
using namespace std;
],[
  string astring="Hallo Welt.";
  astring.erase(0, 6); // now astring is "Welt"
  return 0;
], kde_cv_stl_works=yes,
   kde_cv_stl_works=no)
])


What's the off chance that these files have become a bit too large for anyone 
to effectively manage them?
Comment 3 Amilcar do Carmo Lucas 2004-08-23 14:42:06 UTC
Have you read the FAQ on the website?
There is the USE_EXCEPTIONS flag in the configure.in(.in) file.
Comment 4 Steven T. Hatton 2004-08-23 20:35:21 UTC
Now I remember! I started trying to follow those directions and realized I didn't really understand the autotools well enough, so I started trying to read up on them.  What I found was that the documentation for these tools is not comprehensive.  That is, there is no up-to-date 'big picture' documentation.

I was trying to figure out the difference between a configure.in and a configure.in.in, as well as which files would be modified if I make distclean. I was also confused by the fact that there is no Makefile.dist.  I believe that should be `make -f Makefile.cvs' perhaps?

At about the time I started piecing it all together, the switchover to the new project template system was initiated. The meant nothing worked.  By the time it all finally came back together, I had forgetten about the FAQ.

From the GUI perspective I believe what the user needs to do (with latest KDevelop CVS and a new project) is:

Build->Distclean (if the project has previously been built)

Edit the top-level configure.in.in to add the following:

dnl (I put them at the end of the file)

CXXFLAGS="$CXXFLAGS $USE_EXCEPTIONS"
CXXFLAGS="$CXXFLAGS $USE_RTTI" dnl (if you also want rtti)

And then select Build->Run Automake and Friends

Or simply Build->Build Project

This seems to work, and doesn't force me to reedit the configure.in.in each time I do a distclean on the project.

It would be nice to have the GUI provide the means of modifying these settings somewhere in the project options dialog.  It is very deceptive to provide a field to add compiler options, but to override some of the options the user may add.
Comment 6 Robert Vogl 2004-11-20 16:03:51 UTC
Why is it so hard to get rid of that damned -fno-exception bug? Nine(!) months later this bug is still present in version 3.1.1. When can we expect a proper exception support also in kdevelop?
Comment 7 Matt Rogers 2004-12-10 03:02:33 UTC
for KDE applications, exceptions are disabled by default. To enable exceptions add "KDE_CXXFLAGS = $(USE_EXCEPTIONS)"
Comment 8 Jens Dagerbo 2004-12-14 21:06:47 UTC
*** Bug 93115 has been marked as a duplicate of this bug. ***
Comment 9 Jens Dagerbo 2006-12-16 20:45:16 UTC
As Matt explained, this is standard on KDE applications. Sure, the documentation can always be better, but the template shouldn't change because of this. 

WONTFIX.