Albert Chin wrote on 2005-11-26:
> It's not necessarily safe to assume a system variable/function/header,
> if available to the C compiler, is available to the C++ compiler. This
> is even in the case the same vendor provides the C and C++ compiler.
> For example:
> 1. On Tru64 UNIX 5.1, <stdint.h> is available to the C compiler,
> but not the C++ compiler.
> $ cat test.c
> #include <stdint.h>
> $ cc -c test.c
> $ cp test.c test.cc
> $ cxx -c test.cc
> cxx: Error: test.cc, line 1: could not open source file "stdint.h"
> #include <stdint.h>
> -------------------^
> cxx: Info: 1 error detected in the compilation of "test.cc".
Ouch. Then you will have to perform the autoconf test with the C++ compiler
instead of the C compiler. Use AC_LANG_PUSH([C++]) before the test, and
AC_LANG_POP([C++]) after the test.
> 2. On HP-UX 11.23/IA, <wchar.h> will bring in mbstate_t for the
> C++ compiler, but not the C89 compiler.
> $ cat test.c
> #include <wchar.h>
> $ cc -E test.c | grep mbstate_t
This is invalid, no? I have the following section in the INSTALL file
of GNU gettext:
---------------------------------------------------------------------------
Particular Systems
==================
On HP-UX, the default C compiler is not ANSI C compatible. If GNU CC
is not installed, it is recommended to use the following options in order
to use an ANSI C compiler:
env CC="cc -Ae" ./configure
---------------------------------------------------------------------------
> How do we solve this? We've currently solved it by implementing
> separate defines depending on the language. As an example, I've
> attached our patched mbstate_t.m4 below. We've done something similar
> for inttypes_h.m4, stdint_h.m4, and uintmax_t.m4. Is this the correct
> approach? Ideally, we should autodetect AC_PROG_CXX and build with the
> C++ compiler only if AC_PROG_CXX has been called (AC_PROVIDE_IFELSE?).
I'd suggest to use the stricter among the used language processors. In
this case it's probably C++ for most tests.
No need to change the .m4 files. Adding a pair of
AC_LANG_PUSH([C++])
and
AC_LANG_POP([C++])
in configure.ac should be enough.
Bruno
_______________________________________________
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
