Akim Demaille <[EMAIL PROTECTED]> writes:
> | Index: aclang.m4
> | ===================================================================
> | RCS file: /cvs/autoconf/aclang.m4,v
> | retrieving revision 1.68
> | diff -u -r1.68 aclang.m4
> | --- aclang.m4 2000/10/02 13:11:28 1.68
> | +++ aclang.m4 2000/10/02 17:19:28
> | @@ -412,9 +412,6 @@
> | define([AC_LANG_SOURCE(C++)],
> | [#line __oline__ "configure"
> | #include "confdefs.h"
> | -#ifdef __cplusplus
> | -extern "C" void exit (int);
> | -#endif
> | $1])
>
> I'm in favor of this patch given that it applies only to C++. Note
> however, that it does not solve the problem for people who use
> CC=g++.
Are you sure there _is_ a problem when using CC=g++? I'm at least not
seeing any with this configure.in:
AC_INIT(configure.in)
AC_LANG_C
AC_TRY_COMPILE([#include <stdlib.h>], [], , AC_MSG_ERROR(sorr-ee))
AC_OUTPUT()
..and configure run like this:
$ ./configure CC=g++
Which shouldn't be any surprise, as AC_LANG_SOURCE(C) does not add any
explicit exit() declaration, like AC_LANG_SOURCE(C++) does.
It'd be interesting to know what the ``extern "C" void exit (int);''
was doing there in the first place..?
BTW, the ``#ifdef __cplusplus'' also looks strange, given that the
macro name AC_LANG_SOURCE(C++) seems to assert that we are always
using a C++ compiler to compile the generated source file?
Regards,
Morten
