Re: Error detecting -fno-rtti -fno-exceptions availability under GCC 4

[Ralf Wildenhues]

Hi Luca,

* Luca Fascione wrote on Tue, Jan 24, 2006 at 03:25:59AM CET:
> 
> This script

> Will go and run a macro called AC_LIBTOOL_PROG_COMPILER_NO_RTTI
> which tests the availability of the compiler options -fno-rtti 
> -fno-exceptions by running
> 
> gcc -c -g -O2  -fno-rtti -fno-exceptions  conftest.c >&5
> 
> This, unfortunately, breaks under gcc 4, because the .c extension puts 
> the compiler in C mode (as opposed to C++), hence having it refuse the 
> C++ specific options as above.

Yes.  This in itself doesn't look like a bug to me: for `gcc' we don't
need those flags.  Why do you want them there?

Of course you may still have a point: for `g++' we should detect and use
them correctly.  I believe we do though, except for this code snippet in
AC_LIBTOOL_LANG_CXX_CONFIG:
| # We don't want -fno-exception when 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

> A possible fix would be to run
> 
> gcc -c -g -O2  -fno-rtti -fno-exceptions -x c++ conftest.c >&5

No.  It should be run in the same way as it is used.

> (for example having the macro expand to something on the lines of

> note the added -x c++ only to the actualy compiler invocation).
> 
> This behaviour works fine on gcc 2.96, 3.3.2, 3.4.0, 4.0.1 (which are 
> the ones I could test)

What is the behavior you see in your package, and how does it differ
from your expectation?  I need to understand your need before I can
understand the bug that may be connected with this.

Cheers,
Ralf