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 _______________________________________________ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool