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

[Luca Fascione]

Hello Ralf, thanks for your answer. I now understand from your reply the semantic of the test itself: it is meant to check that, when compiling C sources, rtti and exceptions are disabled. It thought it was needed to verify if when compiling C++ it was possible to disable them... (Which is a whole different thing...) Maybe the message could be phrased in a different way... The macro itself comes from the expansion of AM_PROG_LIBTOOL, which I personally found in the configuration script for Mono, and I was trying to understand why the same test woudl succeed in gcc 3 and not in gcc 4 for such a simple thing... I'm sorry to waste your time, it's just that it looks like a standard test, and that I got the phrasing as meaning something different from what it actually is... About Mono itself, it is a C application, with no C++, so it doesn't really need any of that anycase... I'm sorry, I find the phrasing confusing. Maybe something on the lines of "checking if we need to disable rtti and exceptions explicitly for C" would be less confusing for occasional users... Thank you again Luca Ralf Wildenhues wrote: 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 -- Luca Fascione Pipeline Engineer - Weta Digital +644 380 9815 (x4904) / +64 21 0764 862

_______________________________________________
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool