[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    PATCH: gcc 3 hacks
From:       Dirk Mueller <mueller () kde ! org>
Date:       2001-02-17 14:34:14
[Download RAW message or body]

Hi, 

I've been following gcc/libstdc++-v3 development for a while now and I came 
to the conclusion that they won't be able to sort out the issues before 
release. It took them 4 weeks to include a trivial fix in the headers I 
posted a bugreport, a testcase and a patch for and I'm pretty sure it'll 
take them a few magnitudes longer to fix their lib to work with 
-fno-exceptions, especially as they seem to like to commit half part of the 
patch to HEAD branch (which is post 3.0) and the other half to the 
gcc-3_0-branch and you have to try to sort out which files to get from the 
several incompatible branches in order to get something that doesn't 
segfault during bootstrapping already. 

Ironically, the standard AT&T/SGI implementation is currently also revised 
and adopted to the new specs as well as going under some improvements (read: 
less bloat, more speed). I hope they will somewhen simply adopt the working 
implementation from AT&T and don't waste their efforts on attempting to get 
something else less capable working. At least the common sense should tell 
them to do that. We'll see. 

Anyway, I think the best for now is to add a configure switch for those who 
are using / have to use that new compiler (I'm pretty sure some distros will 
pick it up even before release) to make KDE 2.1 compile in case 
the problems are not yet sorted out in their implementation. 

I'm not sure if we should make the QT_GENUINE_STR test also configureable. 
This is more a clash with the Qt header files (those #define strlen qstrlen) 
and the C++ spec, which requires strlen to be in std:: namespace, so 
libstdc++-v3 headers declare a std::strlen and provide a non-inline 
implementation (who needs speed anyway). the Qt #define will make the 
compiler read that as std::qstrlen and cause an undefined symbol error 
during linking stage. I guess that cannot be resolved before Qt 3 if at all, 
so we're required to use this define in any case. 

Please review. 


Dirk

["patch.configure" (text/plain)]

Index: acinclude.m4.in
===================================================================
RCS file: /home/kde/kde-common/admin/acinclude.m4.in,v
retrieving revision 2.68
diff -u -3 -d -p -r2.68 acinclude.m4.in
--- acinclude.m4.in	2001/02/14 03:02:30	2.68
+++ acinclude.m4.in	2001/02/17 14:12:50
@@ -2239,15 +2239,26 @@ dnl dependecies between AC_PROG_CPP and 
       fi
     fi
 
-    KDE_CHECK_COMPILER_FLAG(fno-exceptions,
+    AC_ARG_ENABLE(no-exceptions, [  --disable-no-exceptions Disable -fno-exceptions [default=no]],
     [
-      CXXFLAGS="$CXXFLAGS -fno-exceptions"
-    ])
+      if test "$enableval" = "no"; then
+        kde_use_noexceptions="no"
+      else
+        kde_use_noexceptions="yes"
+      fi
+    ], [ kde_use_noexceptions="yes"])  
+        
+    if test "$kde_use_noexceptions" = "yes"; then
+      KDE_CHECK_COMPILER_FLAG(fno-exceptions,
+      [
+        CXXFLAGS="$CXXFLAGS -fno-exceptions"
+      ])
+    fi  
       
     if test "$GXX" = "yes"; then
       dnl the libstdc++ v3 shipped with newer gcc's
       dnl does not like Qt's strlen #defines
-      if test  "`$CXX --version`" = "2.97"; then
+      if test "`$CXX --version`" = "3.0"; then
         CXXFLAGS="$CXXFLAGS -DQT_GENUINE_STR"
       fi
     fi   


[prev in list] [next in list] [prev in thread] [next in thread]