Hi Timothée, Your report touches several issues: * Timothée Lecomte wrote on Tue, May 02, 2006 at 02:44:54AM CEST: > > I had to add AC_PROG_CXX and AC_PROG_CXXCPP to the configure.in file. As > many of you may know, they should not be called conditionally, so the > script do call them unconditionally. > > But, of course, users should still be able to compile gnuplot if they > don't have any C++ compiler. In this case, the macro AC_PROG_CXX does not > fail, but sets by default CXX to g++, even if it is not present, This the bug that the second AC_PROG_C* invocation won't fail: http://lists.gnu.org/archive/html/autoconf/2006-03/msg00067.html and I already argued here: http://lists.gnu.org/archive/html/autoconf/2006-04/msg00008.html that it should be fixed, but that it's a bit dangerous to do now. Together with that fix, also a method should be provided to keep the configure script running in case any of AC_PROG_CC/CXX/F77.. fail; packages like yours and Libtool need this additional functionality, otherwise configure would just fail for users without a C++ compiler. [1] Erm, in fact, the documentation does not even state that any of those macros _would_ fail when they fail to find a suitable compiler; AC_PROG_CXX is even documented as: | Otherwise, if the macro is invoked without an argument, then | search for a C++ compiler under the likely names (first `g++' and | `c++' then other names). If none of those checks succeed, then as | a last resort set `CXX' to `g++'. So really this is a very unfortunate situation: we have conflicting expectations as to the correct behavior of the plain macros we have at the moment, and real-world usage in all cases (due to the bug that ordering matters at the moment), and documentation (that states that AC_PROG_CXX won't exit), so fixing this is going to be painful for at least one side. > so that > automake will finally think that the project contains some C++ files, and > use g++ to link the object files. .... And there it fails. Wait; I don't see why this happens. If you list only C files for a program, it won't use the C++ driver for linking. But you may be using Automake conditionals to add C++-compiled objects or so; then Automake does not stand a chance to decide at Automake time. However, even then you should be able to fix this by setting the per-target linker; search for maude_LINK in info Automake "Program and Library Variables" If in doubt, show parts of your Makefile.am so we can find out why Automake (which version BTW?) chooses CXXLINK. > So I did the following : > dnl wxWidgets terminal needs C++ > dnl These tests cannot be called conditionally. > dnl However, even if there is no C++ compiler on the system, > dnl autoconf will set CXX as g++ : this must be reverted. > AC_PROG_CXX > AC_PROG_CXXCPP > Can you comment on this, and tell me if it is sure enough ? It works for > me (autoconf 2.59, I tried it by renaming g++ and c++ to somethings else), > but I would like to be sure that it will work on future autoconf versions. It looks ok for Autoconf-2.59 and CVS as of now, if the AC_PROG_CXX comes after AC_PROG_CC, but depending on how above issues will be fixed, this may need to be revisited. Cheers, Ralf [1] CVS Libtool uses pushdef([AC_MSG_ERROR], [_lt_caught_CXX_error=yes]) AC_PROG_CXX if test -n "$CXX" && ( test "X$CXX" != "Xno" && ( (test "X$CXX" = "Xg++" && `g++ -v >/dev/null 2>&1` ) || (test "X$CXX" != "Xg++"))) ; then AC_PROG_CXXCPP else _lt_caught_CXX_error=yes fi popdef([AC_MSG_ERROR]) to get around this, but that's very ugly, and should be fixed as soon as Autoconf is fixed; besides the fact that it should use m4_pushdef instead of pushdef (2 instances), and (g++ -v) >/dev/null 2>&1 instead of g++ -v >/dev/null 2>&1 (And if you use it in your own code, be sure to rename the variable from Libtool's name space!) _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
